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
ff09eefbe4e8...
ff09eefbe4e8b57846435ee4a928f17e49f0fdfc
Georgi (Joro) Kodinov
MDEV-40815: resolveip is not built for the minbuild cmake target

Added the resolveip target to the minbuild target.
fd6c23d0b864...
fd6c23d0b864e285ef5fbafdd61127b93e7eb8e1
Sergei Golubchik
MDEV-40445 TLS session resumption

in fact it was already on in the server, so this only
enables statistics to see it in SHOW STATUS, adds tests,
and updates C/C to match.

Assisted-By: Claude:claude-5-opus
efe42809212c...
efe42809212cb9e035f22cb38f3724e623927be4
Georgi (Joro) Kodinov
MDEV-40815: resolveip is not built for the minbuild cmake target

Added the resolveip target to the minbuild target.
eb052c342393...
eb052c3423931fdc3646dac25d0e5bc93292b474
bsrikanth-mariadb
MDEV-39226: Push whole multi-table update/delete down into engines

Give storage engines a way to take over an entire multi-table
UPDATE/DELETE, the way they can already take over a SELECT. Without it the
join, the row matching and every modification run in the SQL layer even
when an engine could do the whole statement itself in one step; a
single-table UPDATE/DELETE already avoids this via
direct_update_rows()/direct_delete_rows(), but a multi-table statement has
no primary handler object to drive that path.

This adds a generic, engine-agnostic pushdown interface: the SQL layer
offers the statement to the engine, and if the engine accepts it, it
performs the whole thing and reports only the row counts.

- Split select_handler into a pushdown_handler base with select_handler
  (result set) and a new multi_upddel_handler (runs a whole UPDATE/DELETE,
  reports row counts, reported as PUSHED UPDATE/PUSHED DELETE); add
  handlerton::create_multi_upddel, looked up in Sql_cmd_dml::execute_inner().
- multi_update/multi_delete gain direct_update_delete_done(), which records
  the engine's counts so send_eof() binlogs and replies without the
  SQL-layer loop; it forces statement-format binlogging so the change still
  replicates under binlog_format=ROW, and errors out instead of silently
  dropping counts for an unsupported result object.
- FederatedX implements the interface as the reference engine used to test
  correctness: it prints the statement back and runs it remotely, passes
  the engine's error code/SQLSTATE through, reads the matched count from the
  remote info string, executes IGNORE locally, and only pushes down when all
  tables share one remote server (same as SELECT/derived/unit pushdown).

Test: federated.federatedx_pushdown_upd_del.
e6e8f6ae9a56...
e6e8f6ae9a5608d6202af993f11b25f23409f691
Monty
Fixed wrong error handling in handler::ha_update_row()

- Error could be wrongly ignored
dee6ce030d65...
dee6ce030d653107eb72fbd89a2e0eab7bdcc0ab
Alexander Barkov
MDEV-40790 SELECT INTO row_type_of.field crashes the server

The server crashed on DBUG_ASSERT on a SELECT into:
- a `ROW TYPE OF table1` field variable
- a `ROW TYPE OF cursor1` field variable

Fix:

- Adding a class my_var_sp_row_field_by_name
- Adding a method sp_rcontext::set_variable_row_field_by_name()
- Fixing the DBUG_ASSERT
dd6c4b656265...
dd6c4b656265d161d9a3b93330e609bd02f63470
Monty
Added proper cleanup of main.cte_update_delete.test
c4fae0442b1c...
c4fae0442b1c9a89e41f38bb42594a1b64b3a7ce
ParadoxV5
MDEV-38849 slave_connections_needed_for_purge prevents independent machine from purging binary logs

`@@slave_connections_needed_for_purge`’s default of `1` ensures binary
log availability on replication masters, but is not a sensible default
suitable for all scenarios, especially for long-term slave servers and
standalone (not in a replication setup) servers.
The outcome was that standalone server users were confused why automatic
binlog purging does not work.

This commit changes this default to `0`, which is suitable for both
standalone and (when backed by prompt failure recovery)
replication setups.
`0` also matches the behaviour before MDEV-31404,
which added this variable, more closely out of the box.

This commit also adds a one-time replication warning when registering a
slave, but `@@slave_connections_needed_for_purge` is left unchanged.
Rather than enforcing a defence with an unsensible default, this
reminder will bring awareness of the risk of automatic binlog purging.

This commit also cleans up Galera and MTR workarounds to the
introduction of the `@@slave_connections_needed_for_purge=1` default.
b786b0abfa52...
b786b0abfa527a6b5b80bb54f43c1379093aaf7e
Monty
Removed some not needed checks and a DBUG_ASSERT() for not covered code

- In ha_partition.cc:check_parallel_search(), remove check if
  item_field->field is null. This is not needed as the function is run
  after fix_field() which guarnatees that the field is always set.
- Added DBUG_ASSERT(new_field) to Item_field::fix_fields() to check if a
  select-list item, found by name or alias when resolving ORDER BY/GROUP
  BY/HAVING, can have field == 0. This error path is not covered by any
  mtr test.
b6ebc970953d...
b6ebc970953d16f97b1f1ba4302df9d40f129a4c
Alexander Barkov
MDEV-39563 Implement UPDATE ... RETURNING ... INTO
add639919887...
add63991988734383c5e942de2a19c6c45f511f7
Alexander Barkov
MDEV-40790 SELECT INTO row_type_of.field crashes the server

The server crashed on DBUG_ASSERT on a SELECT into:
- a `ROW TYPE OF table1` field variable
- a `ROW TYPE OF cursor1` field variable

Fix:

- Adding a class my_var_sp_row_field_by_name
- Adding a method sp_rcontext::set_variable_row_field_by_name()
- Fixing the DBUG_ASSERT
ad14b2c659f4...
ad14b2c659f4efb322bab12411b279ff5289e19e
Marko Mäkelä
Avoid unsafe mmap_copy and inefficient sendfile(2)
a9dd9e21a993...
a9dd9e21a9934bc13811bdd21813f813843dec1f
Aleksey Midenkov
MDEV-40799 Runtime plugin/UDF load errors lost under --silent-startup

Regression from MDEV-32745 (7828fb475b0), which guarded the
plugin-load my_error() calls with opt_silent_startup.  That option is
a lifetime global, set once at startup and never reset, so the guard
suppressed the SQL error for the whole server lifetime, not just
during startup.  Runtime operations (INSTALL PLUGIN, CREATE FUNCTION
... SONAME) then skipped my_error(), never set the diagnostics area
and wrongly succeeded - e.g. main.ps's "call proc_1()" no longer
failed with ER_CANT_OPEN_LIBRARY.

Startup callers pass MYF(ME_ERROR_LOG); runtime callers pass MYF(0).
Gate the silencing on that flag via silent_plugin_startup() so it
applies only to the startup error-log path, and runtime errors always
reach the client.

No new test case: the runtime failure path is already covered by
existing tests (e.g. main.ps's ER_CANT_OPEN_LIBRARY check).  The
regression stayed invisible only because stock MTR does not start
servers with --silent-startup.  A dedicated test would have to restart
the server with --silent-startup solely to assert that a startup-only
option does not affect runtime, which adds little over the restored
invariant.
a392c682b51b...
a392c682b51b400c07828cbd7beca605da839d57
Alexander Barkov
MDEV-39563 Implement UPDATE ... RETURNING ... INTO
a04d507b302e...
a04d507b302e5c732a03f8956ec9e1f1cb1c6607
ParadoxV5
MDEV-38849 slave_connections_needed_for_purge prevents independent machine from purging binary logs

`@@slave_connections_needed_for_purge`’s default of `1` ensures binary
log availability on replication masters, but is not a sensible default
suitable for all scenarios, especially for long-term slave servers and
standalone (not in a replication setup) servers.
The outcome was that standalone server users were confused why automatic
binlog purging does not work.

This commit changes this default to `0`, which is suitable for both
standalone and (when backed by prompt failure recovery)
replication setups.
`0` also more closely matches the behaviour before MDEV-31404,
which added this variable, out of the box.

This commit also adds a one-time replication warning when registering a
slave, but `@@slave_connections_needed_for_purge` is left unchanged.
Rather than enforcing a defence with an unsensible default, this
reminder will bring awareness of the risk of automatic binlog purging.

This commit also cleans up Galera and MTR workarounds to the
introduction of the `@@slave_connections_needed_for_purge=1` default.
9170e85d5a1b...
9170e85d5a1b8fa191c0d309e113c6598438fdb7
ParadoxV5
MDEV-38849 slave_connections_needed_for_purge prevents independent machine from purging binary logs

`@@slave_connections_needed_for_purge`’s default of `1` ensures binary
log availability on replication masters, but is not a sensible default
suitable for all scenarios, especially for long-term slave servers and
standalone (not in a replication setup) servers.
The outcome was that standalone server users were confused why automatic
binlog purging does not work.

This commit changes this default to `0`, which is suitable for both
standalone and (when backed by prompt failure recovery)
replication setups.
`0` also more closely matches the behaviour before MDEV-31404,
which added this variable, out of the box.

This commit also adds a one-time replication warning when registering a
slave, but `@@slave_connections_needed_for_purge` is left unchanged.
Rather than enforcing a defence with an unsensible default, this
reminder will bring awareness of the risk of automatic binlog purging.

This commit also cleans up Galera and MTR workarounds to the
introduction of the `@@slave_connections_needed_for_purge=1` default.
8fb1e88279d0...
8fb1e88279d0630af32bdefb20abdadb58d84263
Marko Mäkelä
Reduce buf_pool.mutex contention
8f00e6caca63...
8f00e6caca633c783140db86d3a48a96de67cf38
Marko Mäkelä
MDEV-40756 Incorrect multi-batch recovery of file size

file_name_t::page0_lsn: Keep track of the last applied
recv_sys_t::parse_page0() so that a multi-batch recovery
will not reset the file to a smaller size.

Reviewed by: Thirunarayanan Balathandayuthapani
8cc74b2ad616...
8cc74b2ad6163b020c2048029a84b3d1574d6028
Marko Mäkelä
MDEV-40080: innodb_log_archive=ON corruption

log_t::write_checkpoint(): Extend the the correct file.

log_t::archived_mmap_switch_prepare(): Tolerate a near-concurrent
buf_flush_archive_create() from the buf_flush_page_cleaner() thread.
8b29feadbc81...
8b29feadbc81eeeff480c37bf4f42adecdf7f17e
bsrikanth-mariadb
MDEV-39226: Push whole multi-table update/delete down into engines

Give storage engines a way to take over an entire multi-table
UPDATE/DELETE, the way they can already take over a SELECT. Without it the
join, the row matching and every modification run in the SQL layer even
when an engine could do the whole statement itself in one step; a
single-table UPDATE/DELETE already avoids this via
direct_update_rows()/direct_delete_rows(), but a multi-table statement has
no primary handler object to drive that path.

This adds a generic, engine-agnostic pushdown interface: the SQL layer
offers the statement to the engine, and if the engine accepts it, it
performs the whole thing and reports only the row counts.

- Split select_handler into a pushdown_handler base with select_handler
  (result set) and a new multi_upddel_handler (runs a whole UPDATE/DELETE,
  reports row counts, reported as PUSHED UPDATE/PUSHED DELETE); add
  handlerton::create_multi_upddel, looked up in Sql_cmd_dml::execute_inner().
- multi_update/multi_delete gain direct_update_delete_done(), which records
  the engine's counts so send_eof() binlogs and replies without the
  SQL-layer loop; it forces statement-format binlogging so the change still
  replicates under binlog_format=ROW, and errors out instead of silently
  dropping counts for an unsupported result object.
- FederatedX implements the interface as the reference engine used to test
  correctness: it prints the statement back and runs it remotely, passes
  the engine's error code/SQLSTATE through, reads the matched count from the
  remote info string, executes IGNORE locally, and only pushes down when all
  tables share one remote server (same as SELECT/derived/unit pushdown).

Test: federated.federatedx_pushdown_upd_del.
6c7d9565dd44...
6c7d9565dd448504a7e2e2c725f215853c10bccd
Monty
Removed wrong assert on thd->lex->query_tables != table_list

This was in log_event_server.cc and I got mutiple asserts on this
in valgrind builds, when malloc() returned same address for different
table list (with free() in between)
67cba6e24303...
67cba6e24303c8ae910fe53427276f80a0607fe4
KhaledR57
MDEV-40498 KEY_OP_CHANGE copies length without checking header_end

The KEY_OP_CHANGE branch of _ma_apply_redo_index() passed the length from
the redo record to memcpy() without checking it against the end of that
record, and bounded the destination with a DBUG_ASSERT, which is compiled
out when DBUG_OFF is set. A record claiming more data than it carries
could therefore copy bytes of earlier records into the page, and an
unchecked page offset could put that copy outside the page.

Turn the assert into a runtime check. The logged length and its two
operand bytes must fit in what is left of the record, the page offset
must be set, and offset plus length must stay inside the used page. The
page bound matters on its own: page_offset comes from KEY_OP_OFFSET,
which is still guarded only by a DBUG_ASSERT, and records carrying no
KEY_OP_SHIFT reach the copy with no bound on it at all.

The test forges the logged length with corrupt_change_length and the
logged offset with corrupt_change_offset, then crashes the server so
recovery has to replay the records. Each keyword uses the largest value
the earlier checks accept, so the two cases trip different halves of the
new check.
62de141e4710...
62de141e47107d6aaba9f53649a6412f6dc33930
bsrikanth-mariadb
MDEV-39226: Push whole multi-table update/delete down into engines

Give storage engines a way to take over an entire multi-table
UPDATE/DELETE, the way they can already take over a SELECT. Without it the
join, the row matching and every modification run in the SQL layer even
when an engine could do the whole statement itself in one step; a
single-table UPDATE/DELETE already avoids this via
direct_update_rows()/direct_delete_rows(), but a multi-table statement has
no primary handler object to drive that path.

This adds a generic, engine-agnostic pushdown interface: the SQL layer
offers the statement to the engine, and if the engine accepts it, it
performs the whole thing and reports only the row counts.

- Split select_handler into a pushdown_handler base with select_handler
  (result set) and a new multi_upddel_handler (runs a whole UPDATE/DELETE,
  reports row counts, reported as PUSHED UPDATE/PUSHED DELETE); add
  handlerton::create_multi_upddel, looked up in Sql_cmd_dml::execute_inner().
- multi_update/multi_delete gain direct_update_delete_done(), which records
  the engine's counts so send_eof() binlogs and replies without the
  SQL-layer loop; it forces statement-format binlogging so the change still
  replicates under binlog_format=ROW, and errors out instead of silently
  dropping counts for an unsupported result object.
- FederatedX implements the interface as the reference engine used to test
  correctness: it prints the statement back and runs it remotely, passes
  the engine's error code/SQLSTATE through, reads the matched count from the
  remote info string, executes IGNORE locally, and only pushes down when all
  tables share one remote server (same as SELECT/derived/unit pushdown).

Test: federated.federatedx_pushdown_upd_del.
61d34a8ea300...
61d34a8ea300765317df0e8631f70bcf7e0947c6
Aleksey Midenkov
MDEV-40799 Runtime plugin/UDF load errors lost under --silent-startup

Regression from MDEV-32745 (7828fb475b0), which guarded the
plugin-load my_error() calls with opt_silent_startup.  That option is
a lifetime global, set once at startup and never reset, so the guard
suppressed the SQL error for the whole server lifetime, not just
during startup.  Runtime operations (INSTALL PLUGIN, CREATE FUNCTION
... SONAME) then skipped my_error(), never set the diagnostics area
and wrongly succeeded - e.g. main.ps's "call proc_1()" no longer
failed with ER_CANT_OPEN_LIBRARY.

Startup callers pass MYF(ME_ERROR_LOG); runtime callers pass MYF(0).
Gate the silencing on that flag via silent_plugin_startup() so it
applies only to the startup error-log path, and runtime errors always
reach the client.
61307aec0c6a...
61307aec0c6ae2ab312793a500abfef220c2d7a1
Sergei Golubchik
disable DBUG in plugins, better deb version detection

dbug can be enabled with -UDBUG_OFF, if *really* needed
5c52cc50f5a5...
5c52cc50f5a5997aba2e1b32179a879c8edee98e
Yuchen Pei
MDEV-40805 Do not call lock_rec_convert_impl_to_expl if a table S-lock is held

In lock_clust_rec_read_check_and_lock there's a test on
lock_table_has(trx, index->table, LOCK_X) which if fails would result
in a call to lock_rec_convert_impl_to_expl<true>, which 1. has a
comment "If an implicit x-lock exists on a record, convert it to an
explicit one." that does not apply if a table S-lock is held and 2.
does a few things such as looking up the trx_id of the record and find
the trx in a global hash trx_sys. In this patch we do the same check
for a table S-lock when no record locks implicit or explicit could be
held
587e34e4afd2...
587e34e4afd2a9a412b1317d703086150ab2f734
Alexander Barkov
Cherry-pick from 12.3: MDEV-40790 SELECT INTO row_type_of.field crashes the server

The server crashed on DBUG_ASSERT on a SELECT into:
- a `ROW TYPE OF table1` field variable
- a `ROW TYPE OF cursor1` field variable

Fix:

- Adding a class my_var_sp_row_field_by_name
- Adding a method sp_rcontext::set_variable_row_field_by_name()
- Fixing the DBUG_ASSERT
50d0c98c62a4...
50d0c98c62a4523586e46fa4999a07d943866d04
Alexander Barkov
Cherry-pick from 12.3: MDEV-40790 SELECT INTO row_type_of.field crashes the server

The server crashed on DBUG_ASSERT on a SELECT into:
- a `ROW TYPE OF table1` field variable
- a `ROW TYPE OF cursor1` field variable

Fix:

- Adding a class my_var_sp_row_field_by_name
- Adding a method sp_rcontext::set_variable_row_field_by_name()
- Fixing the DBUG_ASSERT
508c1cd9d76c...
508c1cd9d76c1677986a21f5f3d096bf6891a077
Sergei Golubchik
MDEV-40445 TLS session resumption (wolfssl)

* enable HAVE_SESSION_TICKET to allow resumption
* enable OPENSSL_ALL+KEEP_PEER_CERT to keep peer cert in the ticket,
  otherwise REQUIRE SUBJECT doesn't work after resumption
* disable OPENSSL_EXTRA which was enabled as a replacement
  when OPENSSL_ALL was disabled in 136e8661197
* disable NO_WOLFSSL_STUB to get SSL_CTX_sess_hits/etc stubs
* but they're stubs, always return 0, so add a wolfssl combination to
  the test that checks for these values
4cf00d32212f...
4cf00d32212f660c8149f25a510942658f73b6a7
Marko Mäkelä
Avoid inefficient file-to-file sendfile(2)

FIXME: Refactor the APIs to try mmap() only once per file
3523ffdf971f...
3523ffdf971f60d8d91f571618c768057fae4632
sjaakola
MDEV-36677 rsync sst fails with different innodb_log_group_home_dir and datadir

Backported the fix done by Pekka Lampio for mariaDB 11.4 in PR
https://github.com/mariadb-corporation/codership-mariadb-server/pull/543

The PR has a fix for wsrep_sst_rsync script and new mtr test:
galera_3nodes.galera_mdev_36677" to check that the rsync SST method of Galera
works correctly also when the joiner node store InnoDB log files in a dedicated
directory separate from the data dictionary

Note: merging this PR to 11.4 may not be fully functional as there are other
changes in the rsync SST script. Take a look at the original 11.4 PR when merging.
3496f1607305...
3496f16073051a5afc288ce518e2b01a0273d531
Alexander Barkov
MDEV-40790 SELECT INTO row_type_of.field crashes the server

The server crashed on DBUG_ASSERT on a SELECT into:
- a `ROW TYPE OF table1` field variable
- a `ROW TYPE OF cursor1` field variable

Fix:

- Adding a class my_var_sp_row_field_by_name
- Adding a method sp_rcontext::set_variable_row_field_by_name()
- Fixing the DBUG_ASSERT
30d18c74c002...
30d18c74c0026320a87362c499c4f7e680bcbfb2
ParadoxV5
MDEV-38849 slave_connections_needed_for_purge prevents independent machine from purging binary logs

`@@slave_connections_needed_for_purge`’s default of `1` ensures binary
log availability on replication masters, but is not a sensible default
suitable for all scenarios, especially for long-term slave servers and
standalone (not in a replication setup) servers.
The outcome was that standalone servers users were confused why
automatic binlog purging does not work.

This commit changes this default to `0`, which is suitable for both
standalone and, when backed by prompt failure recovery, replication setups.
`0` also matches the behavior before MDEV-31404 added this variable closer out-of-box.

This commit also adds a one-time replication warning when registering a
slave, but `@@slave_connections_needed_for_purge` is left unchanged.
Rather than enforcing a defence with an unsensible default, this
reminder will bring awareness of the risk of automatic binlog purging.

This commit also cleans up Galera and MTR workarounds to the
introduction of the `@@slave_connections_needed_for_purge=1` default.
1a052f27e374...
1a052f27e374fc9b4cb5b1fd098cf10f0e1381cc
Sergei Golubchik
rocksdb: don't abort early in submodule update

Fix for 1fb075512a7aeab8646a163cbb6f265c49f4c075 to allow
the ADD_SUBMODULE to perform updates.
14a06fbba09a...
14a06fbba09a9b946cf8528ebce6bdf2ffc38246
KhaledR57
MDEV-40498 KEY_OP_CHANGE copies length without checking header_end

The KEY_OP_CHANGE branch of _ma_apply_redo_index() passed the length from
the redo record to memcpy() without checking it against the end of that
record, and bounded the destination with a DBUG_ASSERT, which is compiled
out when DBUG_OFF is set. A record claiming more data than it carries
could therefore copy bytes of earlier records into the page, and an
unchecked page offset could put that copy outside the page.

Turn the assert into a runtime check. The logged length and its two
operand bytes must fit in what is left of the record, the page offset
must be set, and offset plus length must stay inside the used page. The
page bound matters on its own: page_offset comes from KEY_OP_OFFSET,
which is still guarded only by a DBUG_ASSERT, and records carrying no
KEY_OP_SHIFT reach the copy with no bound on it at all.

The test forges the logged length with corrupt_change_length and the
logged offset with corrupt_change_offset, then crashes the server so
recovery has to replay the records. Each keyword uses the largest value
the earlier checks accept, so the two cases trip different halves of the
new check.
0f07d75824b9...
0f07d75824b9c282005d94adeb590905cf4c9c4e
Alexander Barkov
MDEV-40790 SELECT INTO row_type_of.field crashes the server

The server crashed on DBUG_ASSERT on a SELECT into:
- a `ROW TYPE OF table1` field variable
- a `ROW TYPE OF cursor1` field variable

Fix:

- Adding a class my_var_sp_row_field_by_name
- Adding a method sp_rcontext::set_variable_row_field_by_name()
- Fixing the DBUG_ASSERT
0d3ce7a6ae41...
0d3ce7a6ae415a043aeccf221670c2a19c6b2a3f
Monty
Added proper cleanup of main.cte_update_delete.test
0bcefd01403e...
0bcefd01403e925259a9fe00deabf52fce8163ea
Monty
Removed some not needed checks and a DBUG_ASSERT() for not covered code

- In ha_partition.cc:check_parallel_search(), remove check if
  item_field->field is null. This is not needed as the function is run
  after fix_field() which guarnatees that the field is always set.
- Added DBUG_ASSERT(new_field) to Item_field::fix_fields() to check if a
  select-list item, found by name or alias when resolving ORDER BY/GROUP
  BY/HAVING, can have field == 0. This error path is not covered by any
  mtr test.
BuildBot (0.8.9) working for the MariaDB project.
Page built: Tue 18 Aug 2026 12:40:08 (UTC)