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
  EXPLAIN DELETE FROM t1.* USING t1
  EXPLAIN DELETE b FROM t1 AS a JOIN t1 AS b
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)
Sachin
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
transactional.

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
handle_slave_sql.
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