Home - Waterfall Grid T-Grid Console Builders Recent Builds Buildslaves Changesources - JSON API - About

Console View


Categories: connectors experimental galera main
Legend:   Passed Failed Warnings Failed Again Running Exception Offline No data

connectors experimental galera main
e2088ce4d96a...
e2088ce4d96a6dda8100f1d51bbbf554aa9fa9dc
Alexey Yurchenko
MDEV-38383 Fix MDEV-38073 MTR test warning

MDEV-38073 MTR test started to fail with a warning after upstream merge
from 11.4 a7528a6190807281d3224e4e67a9b76083a202a6 because THD responsible
for creating SST user became read-only when the server was started with
--transaction-read-only=TRUE.
make sure the readonly flag on THDs created for wsp::thd utility class is
cleared regardless of the --transaction-read-only value as it is intended
only for client-facing THDs.
d5db6c1daa13...
d5db6c1daa132acc85dfbbdd35724031db6843fe
Hemant Dangi
MDL BF-BF conflict on ALTER and INSERT with multi-level foreign key parents

Issue:
On galera write node INSERT statements does not acquire MDL locks on it's all child
tables and thereby wsrep certification keys are also added for limited tables, but
on applier nodes it does acquire MDL locks for all child tables. This can result
into MDL BF-BF conflict on applier node when transactions referring to parent and
child tables are executed concurrently. For example:

Tables with foreign keys: t1<-t2<-t3<-t4
Conflicting transactions: INSERT t1 and DROP TABLE t4

Wsrep certification keys taken on write node:
- for INSERT t1: t1 and t2
- for DROP TABLE t4: t4

On applier node MDL BF-BF conflict happened between two transaction because
MDL locks on t1, t2, t3 and t4 were taken for INSERT t1, which conflicted
with MDL lock on t4 taken by DROP TABLE t4.
The Wsrep certification keys helps in resolving this MDL BF-BF conflict by
prioritizing and scheduling concurrent transactions. But to generate Wsrep
certification keys it needs to open and take MDL locks on all the child tables.

On applier nodes Write_rows event is implicitly a REPLACE, deleting all conflicting
rows which can cause cascading FK actions and locks on foreign key children tables.

Solution:
For Galera applier nodes the Write_rows event is considered pure INSERT
which will never cause cascading FK actions and locks on foreign key children tables.
d3571c3bf7c3...
d3571c3bf7c365c4fee989944bd9fe992788446d
Oleg Smirnov
MDEV-38129 Match probability
cb549276caaa...
cb549276caaac6391e5f9f254a8a6399d654af42
ParadoxV5
I think it’s missing this guard.

---

Also: a fix on the commit message:
```md
To avoid conflicts at their root, this commit reïmplements
`@@gtid_ignore_duplicates` so it no longer depends on
`@@sql_slave_skip_counter`. The new implementation is located next to
`@@slave_skip_counter` and utilizes the existing
`rpl_group_info::gtid_ignore_duplicate_state` infrastructure, which was
only used to update states, not by `@@gtid_ignore_duplicates` itself.
```
b29d3779e42f...
b29d3779e42f1cf65b1bbe84876767122dcc76c8
Sergei Golubchik
Merge branch '10.6' into 10.11
a9e353e84f15...
a9e353e84f15c8386e756ef1a49ccde227d2d48b
Monty
MDEV-38246 aria_read index failed on encrypted database during backup

The backup of encrypted Aria tables was not supported.
Added support for this. One complication is that the page checksum is
for the not encrypted page. To be able to verify the checksum I have to
temporarly decrypt the page.
In the backup we store the encrypted pages.

Other things:
- Fixed some (not critical) memory leaks in mariabackup
a2b62fe57257...
a2b62fe57257b1563b5078ddd4934fef9f3b3c3b
Sergei Golubchik
MDEV-38246 aria_read index failed on encrypted database during backup

Skip an all-zero pages in the index file.
They can happen normally if the ma_checkpoint_background
thread flushes some later page first (e.g. page 50 before page 48).

Also:
* don't do alloca() in a loop
* correct the check in ma_crypt_index_post_read_hook(),
  the page can be completely full
* compilation failure in ma_open.c:1289:
  comparison is always false due to limited range of data type
9bfea48ce121...
9bfea48ce1214cc4470f6f6f8a4e30352cef84e7
Sergei Golubchik
Merge branch '11.4' into 11.8
9749d71f9527...
9749d71f9527822a2a16f0a900f7d06e4889ec7e
Sergei Golubchik
MDEV-38709 ASAN heap-buffer-overflow in my_convert_using_func

Don't forget up to update stored_rec_length
when extending temp table reclength.

Followup for 4f9a13e9ecf2
94066148ec97...
94066148ec970e96525ce799627edc41c3ea061a
Sergei Golubchik
Merge remote-tracking branch 'github/11.8' into bb-11.8-serg
8906e6a214ab...
8906e6a214ab7d151e44c994cd9149fe3d45d114
Aleksey Midenkov
MDEV-32317 ref_ptrs exhaust on multiple ORDER by func from winfunc

Each ORDER and WHERE slot may generate split, see code like this:

  if ((item->with_sum_func() && item->type() != Item::SUM_FUNC_ITEM) ||
    item->with_window_func())
  item->split_sum_func(thd, ref_ptrs, all_fields, SPLIT_SUM_SELECT);

Such kind of code is done in JOIN::prepare(), setup_order(),
setup_fields(), setup_group() and split_sum_func2() itself.

Since we are at the phase of ref_ptrs allocation, items are not fixed
yet and we cannot calculate precisely how much ref_ptrs is needed. We
can estimate at most how much is needed. In the worst case each window
function generates split on each ORDER BY field, GROUP BY field and
WHERE field, so the counts of these should be multiplied by window
funcs count.

As the split can be done in both setup_without_group() and
JOIN::prepare() simultaneously, the factor of window funcs should be
multiplied by 2.

The similar case may be with inner sumfunc items as of the condition

  item->with_sum_func() && item->type() != Item::SUM_FUNC_ITEM

but factor of these is harder to predict at the stage of unfixed
items.
8070033e475d...
8070033e475d34b0ba311c5e522b438849a10bd6
Yuchen Pei
MDEV-36230 Fix SERVER port field bound check

The Port field in the system table mysql.servers has type INT,
which translates to Field_long.

During parsing it is parsed as ulong_num, and in this patch we add
bound checks there.
7614f8fb5d0f...
7614f8fb5d0f6f808ac261edf689c1eceede5cd9
Marko Mäkelä
MDEV-38589: SELECT unnecessarily waits for log write

The design of "binlog group commit" involves carrying some state across
transaction boundaries. This includes trx_t::commit_lsn, which keeps track
of how much write-ahead log needs to be written. Unfortunately, this
field was not reset in a commit where a log write was elided. That would
cause an unnecessary wait in a subsequent read-only transaction that
happened to reuse the same transaction object.

trx_deregister_from_2pc(): Reset trx->commit_lsn so that
an earlier write that was executed in the same client connection
will not result in an unnecessary wait during a subsequent read
operation.

trx_commit_complete_for_mysql(): Unless we are inside a binlog
group commit, reset trx->commit_lsn.

unlock_and_close_files(): Reset trx->commit_lsn after durably
writing the log, and remove a redundant log write call from some
callers.

trx_t::rollback_finish(): Clear commit_lsn, because a rolled-back
transaction will not need to be durably written.

trx_t::clear_and_free(): Wrapper function to suppress a debug check
in trx_t::free().

Also, remove some redundant ut_ad(!trx->will_lock) that will be checked
in trx_t::free().

Reviewed by: Vladislav Vaintroub
4802bfe4f907...
4802bfe4f9071c2963980fa8c913aee1577a0187
Sergei Golubchik
MDEV-38710 Assertion is_lock_owner on error returning from auto-create in mysql_admin_table

don't auto-add new partitions if we're already at TIMESTAMP_MAX_VALUE
44a1bb68d20a...
44a1bb68d20a8cb62ea92d4d6e1a88cc9d06801d
Sergei Golubchik
Merge branch 'bb-11.4-serg' into bb-11.8-serg
3218602d3100...
3218602d3100db9ce7a875511a591cddc173cc16
Brandon Nesterenko
MDEV-25039: MDL BF-BF conflict because of foreign key

Fix rpl suite tests added by MDEV-25039.

rpl_foreign_key_lock_table_insert.test is removed altogether because it
is unclear what the purpose of the test is. The changes of the patch
were done on the slave, yet all operations in the test were done on the
master. Nothing different could happen on the slave because it is
configured to be serial, so all transactions would run sequentially
anyway, and no validations were performed.

rpl_foreign_key_ddl_insert.test was renamed to
rpl_row_foreign_key_mdl.test and the test itself was re-written to be
a minimal test case to ensure that MDL locking behavior is different
pre- and post- patch. A few problems with the original test:
* No foreign-key locking was done on the slave because the table
  engine was not InnoDB.
* rpl_fk_ddl.inc had inconsistent validation checking. I.e., the child
  query validation checks were done on the master (which is incorrect)
  and because the slave was configured to be serial, the two
  transactions could not run concurrently on the slave anyway.
0d4af962e891...
0d4af962e89111243dc32deb9a02756e87119f36
ParadoxV5
Merge branch '10.11' into MDEV-38636
05e6c9d42d2f...
05e6c9d42d2f49ada1a0c49a4e0d7fc3ce420e4e
Sergei Golubchik
MDEV-32317 fix the test for --view
054a893f1645...
054a893f1645b77e52a329a7fc8cf614eebd1fad
Sergei Golubchik
Merge branch '10.11' into 11.4
BuildBot (0.8.9) working for the MariaDB project.
Page built: Sun 01 Feb 2026 07:38:30 (UTC)