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
Dmitry Shulga
MDEV-25006: Failed assertion on executing EXPLAIN DELETE statement as a prepared statement

Attempt to execute EXPLAIN statement on multi-table DELETE statement
leads to firing firing of the assertion
  DBUG_ASSERT(! is_set());
in the method Diagnostics_area::set_eof_status.

For example, above mentioned assertion failure happens
in case any of the following statements
are executed in prepared statement mode provided the table t1
does exist.

This assertion is hit by the reason that a status of
Diagnostics_area is set twice. The first time it is set from
the function do_select() when the method multi_delete::send_eof()
called. The second time it is set when the method
Explain_query::send_explain() calls the method select_send::send_eof
(this method invokes the method Diagnostics_area::set_eof_status that
finally hits assertion)

The second invocation for a setter method of the class Diagnostics_area
is correct and run to send a response containing explain data.

But first invocation of a setter method of the class Diagnostics_area
is wrong since the function do_select() shouldn't be called at all
for handling of the EXPLAIN statement.

The reason by that the function do_select() is called during handling of
the EXPLAIN statement is that the flag SELECT_DESCRIBE not set in the
data member JOIN::select_options. The flag SELECT_DESCRIBE
if is copied from values select_lex->options.

During parsing of EXPLAIN statement this flag is set but latter reset
from the function reinit_stmt_before_use() that is called on
execution of prepared statement.
  void reinit_stmt_before_use(THD *thd, LEX *lex)
    for (; sl; sl= sl->next_select_in_list())
      if (sl->changed_elements & TOUCHED_SEL_COND)
        /* remove option which was put by mysql_explain_union() */
        sl->options&= ~SELECT_DESCRIBE;

So, to fix the issue the flag SELECT_DESCRIBE is set forcibly at the
mysql_select() function in case thd->lex->describe set,
that is in case EXPLAIN being executed.
Thirunarayanan Balathandayuthapani
MDEV-20648 InnoDB: Failing assertion: !(*node)->being_extended, innodb.log_data_file_size failed in buildbot, assertion `!space->is_stopping()'

InnoDB should check whether the tablespace is being deleted
while extending the tablespace.
Eugene Kosov
MDEV-24883 add io_uring support for tpool

liburing is a new optional dependency

aio_uring: class which wraps io_uring stuff

aio_uring::bind()/unbind(): optional optimization

aio_uring::submit_io(): mutex prevents data race. liburing calls are
thread-unsafe. But if you look into it's implementation you'll see
atomic operations. They're used for synchronization between kernel and
user-space only. That's why our own synchronization is still needed.

Don't link with Linux AIO when liburing is used.
Vladislav Vaintroub
MDEV-9077 add sys schema
Daniel Black
fix: win
Rinat Ibragimov
MDEV-6536 make --bind=hostname to listen on both IPv6 and IPv4 addresses

Binding to a hostname now makes MariaDB server to listen on all addresses
that hostname resolves to.

Rebased to 10.6 by Daniel Black

Closes: #1668
Marko Mäkelä
Merge 10.2 into 10.3
Sergei Golubchik
mtr --gdb: fix for --rr and for a warning

use _RR_TRACE_DIR=dir instead of -o dir, as the former can store
multiple traces in dir (if, e.g., the test restarts mysqld)

suppress uninitialized warning when $exe is undefined (--manual-XXX)
MDEV-19157 Optimistic Parallel Replication fails when gtid_slave_pos table is non transnational and binlog events are transnational

Problem:- In Optimistic/Aggressive mode of parallel replication when we have
conflict, we retry the transaction, But if gtid_slave_pos is non transactional
In that case retry may result into duplicate key error for table because
the conflicted transaction can not rollback the changes in gtid_slave_pos table
So when we try the same trans again, We get the Duplicate Key error

Solution:- Users are advised to use transactional storage engine for gtid_slave_pos.
In this patch we are throwing warning when we see that gtid_slave_pos in non

Working:- is_gtid_slave_pos_transactional variable is added into rpl_slave_state
which will take care of caching result of gtid_slave_pos transactionality
We are updating this variable in find_gtid_pos_tables_cb, this function will
be called for each gtid_slave_pos_XYZ table at the time of start slave by
We are also checking for opt_gtid_pos_auto_plugins while giving warning
because it can be possible that respective gtid_slave_pos_XYZ table has
not been created yet but user has set the variable.
Vladislav Vaintroub
MDEV-9077 Use sys schema in bootstrapping, incl. mtr

and fix existing mtr cases
Vladislav Vaintroub