lp:maria

Author: Vlad Lesin
Author Date: 2023-07-03 13:04:15 UTC

MDEV-10962 Deadlock with 3 concurrent DELETEs by unique key

PROBLEM:
A deadlock was possible when a transaction tried to "upgrade" an already
held Record Lock to Next Key Lock.

SOLUTION:
This patch is based on observations that:
(1) a Next Key Lock is equivalent to Record Lock combined with Gap Lock
(2) a GAP Lock never has to wait for any other lock
In case we request a Next Key Lock, we check if we already own a Record
Lock of equal or stronger mode, and if so, then we change the requested
lock type to GAP Lock, which we either already have, or can be granted
immediately, as GAP locks don't conflict with any other lock types.
(We don't consider Insert Intention Locks a Gap Lock in above statements).

The reason of why we don't upgrage Record Lock to Next Key Lock is the
following.

Imagine a transaction which does something like this:

for each row {
    request lock in LOCK_X|LOCK_REC_NOT_GAP mode
    request lock in LOCK_S mode
}

If we upgraded lock from Record Lock to Next Key lock, there would be
created only two lock_t structs for each page, one for
LOCK_X|LOCK_REC_NOT_GAP mode and one for LOCK_S mode, and then used
their bitmaps to mark all records from the same page.

The situation would look like this:

request lock in LOCK_X|LOCK_REC_NOT_GAP mode on row 1:
// -> creates new lock_t for LOCK_X|LOCK_REC_NOT_GAP mode and sets bit for
// 1
request lock in LOCK_S mode on row 1:
// -> notices that we already have LOCK_X|LOCK_REC_NOT_GAP on the row 1,
// so it upgrades it to X
request lock in LOCK_X|LOCK_REC_NOT_GAP mode on row 2:
// -> creates a new lock_t for LOCK_X|LOCK_REC_NOT_GAP mode (because we
// don't have any after we've upgraded!) and sets bit for 2
request lock in LOCK_S mode on row 2:
// -> notices that we already have LOCK_X|LOCK_REC_NOT_GAP on the row 2,
// so it upgrades it to X
    ...etc...etc..

Each iteration of the loop creates a new lock_t struct, and in the end we
have a lot (one for each record!) of LOCK_X locks, each with single bit
set in the bitmap. Soon we run out of space for lock_t structs.

If we create LOCK_GAP instead of lock upgrading, the above scenario works
like the following:

// -> creates new lock_t for LOCK_X|LOCK_REC_NOT_GAP mode and sets bit for
// 1
request lock in LOCK_S mode on row 1:
// -> notices that we already have LOCK_X|LOCK_REC_NOT_GAP on the row 1,
// so it creates LOCK_S|LOCK_GAP only and sets bit for 1
request lock in LOCK_X|LOCK_REC_NOT_GAP mode on row 2:
// -> reuses the lock_t for LOCK_X|LOCK_REC_NOT_GAP by setting bit for 2
request lock in LOCK_S mode on row 2:
// -> notices that we already have LOCK_X|LOCK_REC_NOT_GAP on the row 2,
// so it reuses LOCK_S|LOCK_GAP setting bit for 2

In the end we have just two locks per page, one for each mode:
LOCK_X|LOCK_REC_NOT_GAP and LOCK_S|LOCK_GAP.
Another benefit of this solution is that it avoids not-entirely
const-correct, (and otherwise looking risky) "upgrading".

The fix was ported from
mysql/mysql-server@bfba840dfa7794b988c59c94658920dbe556075d
mysql/mysql-server@75cefdb1f73b8f8ac8e22b10dfb5073adbdfdfb0

Reviewed by: Marko Mäkelä

Author: Yuchen Pei
Author Date: 2023-07-05 07:53:12 UTC

MDEV-31117 clean up spider connection info parsing

Spider connection string is a comma-separated parameter definitions,
where each definition is of the form "<param_title> <param_value>",
where <param_value> is quote delimited on both ends, with backslashes
acting as an escaping prefix.

The code however treated param title the same way as param value when
assigning, and have nonsensical fields like delim_title_len and
delim_title. We remove these.

We also clean up the spider comment connection string parsing,
including:

- Factoring out some code from the parsing function
- Rewriting the struct `st_spider_param_string_parse`, including
  replacing its messy methods with cleaner ones
- And any necessary changes caused by the above changes

Author: Rucha Deodhar
Author Date: 2023-07-05 11:05:01 UTC

MDEV-23187 misses resetting collation connection

MDEV-23187 misses resetting collation connection causing test failures for
10.5+ bugs.

Author: Yuchen Pei
Author Date: 2023-07-05 07:55:30 UTC

MDEV-31117 clean up spider connection info parsing

Spider connection string is a comma-separated parameter definitions,
where each definition is of the form "<param_title> <param_value>",
where <param_value> is quote delimited on both ends, with backslashes
acting as an escaping prefix.

The code however treated param title the same way as param value when
assigning, and have nonsensical fields like delim_title_len and
delim_title. We remove these.

We also clean up the spider comment connection string parsing,
including:

- Factoring out some code from the parsing function
- Rewriting the struct `st_spider_param_string_parse`, including
  replacing its messy methods with cleaner ones
- And any necessary changes caused by the above changes

Author: Yuchen Pei
Author Date: 2023-07-05 07:53:12 UTC

MDEV-31117 clean up spider connection info parsing

Spider connection string is a comma-separated parameter definitions,
where each definition is of the form "<param_title> <param_value>",
where <param_value> is quote delimited on both ends, with backslashes
acting as an escaping prefix.

The code however treated param title the same way as param value when
assigning, and have nonsensical fields like delim_title_len and
delim_title. We remove these.

We also clean up the spider comment connection string parsing,
including:

- Factoring out some code from the parsing function
- Rewriting the struct `st_spider_param_string_parse`, including
  replacing its messy methods with cleaner ones
- And any necessary changes caused by the above changes

Author: Yuchen Pei
Author Date: 2023-06-23 07:10:01 UTC

MDEV-31524 Fixing spider table param / variable overriding

The existing (incorrect) overriding mechanism is:

Non-minus-one var value overrides table param overrides default value.

Before MDEV-27169, unspecified var value is -1. So if the user sets
both the var to be a value other than -1 and the table param, the var
value will prevail, which is incorrect.

After MDEV-27169, unspecified var value is default value. So if the
user does not set the var but sets the table param, the default value
will prevail, which is even more incorrect.

This patch fixes it so that table param, if specified, always
overrides var value, and the latter if not specified or set to -1,
falls back to the default value

We achieve this by replacing all such overriding in spd_param.cc with
macros that override in the correct way, and removing all the
"overriding -1" lines involving table params in
spider_set_connect_info_default() except for those table params not
defined as sysvar/thdvar in spd_params.cc

We also introduced macros for non-overriding sysvar and thdvar, so
that the code is cleaner and less error-prone

In server versions where MDEV-27169 has not been applied, we also
backport the patch, that is, replacing -1 default values with real
default values

In server versions where MDEV-28006 has not been applied, we do the
same for udf params

Author: Vlad Lesin
Author Date: 2023-07-03 13:04:15 UTC

MDEV-10962 Deadlock with 3 concurrent DELETEs by unique key

PROBLEM:
A deadlock was possible when a transaction tried to "upgrade" an already
held Record Lock to Next Key Lock.

SOLUTION:
This patch is based on observations that:
(1) a Next Key Lock is equivalent to Record Lock combined with Gap Lock
(2) a GAP Lock never has to wait for any other lock
In case we request a Next Key Lock, we check if we already own a Record
Lock of equal or stronger mode, and if so, then we change the requested
lock type to GAP Lock, which we either already have, or can be granted
immediately, as GAP locks don't conflict with any other lock types.
(We don't consider Insert Intention Locks a Gap Lock in above statements).

The reason of why we don't upgrage Record Lock to Next Key Lock is the
following.

Imagine a transaction which does something like this:

for each row {
    request lock in LOCK_X|LOCK_REC_NOT_GAP mode
    request lock in LOCK_S mode
}

If we upgraded lock from Record Lock to Next Key lock, there would be
created only two lock_t structs for each page, one for
LOCK_X|LOCK_REC_NOT_GAP mode and one for LOCK_S mode, and then used
their bitmaps to mark all records from the same page.

The situation would look like this:

request lock in LOCK_X|LOCK_REC_NOT_GAP mode on row 1:
// -> creates new lock_t for LOCK_X|LOCK_REC_NOT_GAP mode and sets bit for
// 1
request lock in LOCK_S mode on row 1:
// -> notices that we already have LOCK_X|LOCK_REC_NOT_GAP on the row 1,
// so it upgrades it to X
request lock in LOCK_X|LOCK_REC_NOT_GAP mode on row 2:
// -> creates a new lock_t for LOCK_X|LOCK_REC_NOT_GAP mode (because we
// don't have any after we've upgraded!) and sets bit for 2
request lock in LOCK_S mode on row 2:
// -> notices that we already have LOCK_X|LOCK_REC_NOT_GAP on the row 2,
// so it upgrades it to X
    ...etc...etc..

Each iteration of the loop creates a new lock_t struct, and in the end we
have a lot (one for each record!) of LOCK_X locks, each with single bit
set in the bitmap. Soon we run out of space for lock_t structs.

If we create LOCK_GAP instead of lock upgrading, the above scenario works
like the following:

// -> creates new lock_t for LOCK_X|LOCK_REC_NOT_GAP mode and sets bit for
// 1
request lock in LOCK_S mode on row 1:
// -> notices that we already have LOCK_X|LOCK_REC_NOT_GAP on the row 1,
// so it creates LOCK_S|LOCK_GAP only and sets bit for 1
request lock in LOCK_X|LOCK_REC_NOT_GAP mode on row 2:
// -> reuses the lock_t for LOCK_X|LOCK_REC_NOT_GAP by setting bit for 2
request lock in LOCK_S mode on row 2:
// -> notices that we already have LOCK_X|LOCK_REC_NOT_GAP on the row 2,
// so it reuses LOCK_S|LOCK_GAP setting bit for 2

In the end we have just two locks per page, one for each mode:
LOCK_X|LOCK_REC_NOT_GAP and LOCK_S|LOCK_GAP.
Another benefit of this solution is that it avoids not-entirely
const-correct, (and otherwise looking risky) "upgrading".

The fix was ported from
mysql/mysql-server@bfba840dfa7794b988c59c94658920dbe556075d
mysql/mysql-server@75cefdb1f73b8f8ac8e22b10dfb5073adbdfdfb0

Reviewed by: Marko Mäkelä

Author: Vlad Lesin
Author Date: 2023-07-03 13:04:15 UTC

MDEV-10962 Deadlock with 3 concurrent DELETEs by unique key

PROBLEM:
A deadlock was possible when a transaction tried to "upgrade" an already
held Record Lock to Next Key Lock.

SOLUTION:
This patch is based on observations that:
(1) a Next Key Lock is equivalent to Record Lock combined with Gap Lock
(2) a GAP Lock never has to wait for any other lock
In case we request a Next Key Lock, we check if we already own a Record
Lock of equal or stronger mode, and if so, then we change the requested
lock type to GAP Lock, which we either already have, or can be granted
immediately, as GAP locks don't conflict with any other lock types.
(We don't consider Insert Intention Locks a Gap Lock in above statements).

The reason of why we don't upgrage Record Lock to Next Key Lock is the
following.

Imagine a transaction which does something like this:

for each row {
    request lock in LOCK_X|LOCK_REC_NOT_GAP mode
    request lock in LOCK_S mode
}

If we upgraded lock from Record Lock to Next Key lock, there would be
created only two lock_t structs for each page, one for
LOCK_X|LOCK_REC_NOT_GAP mode and one for LOCK_S mode, and then used
their bitmaps to mark all records from the same page.

The situation would look like this:

request lock in LOCK_X|LOCK_REC_NOT_GAP mode on row 1:
// -> creates new lock_t for LOCK_X|LOCK_REC_NOT_GAP mode and sets bit for
// 1
request lock in LOCK_S mode on row 1:
// -> notices that we already have LOCK_X|LOCK_REC_NOT_GAP on the row 1,
// so it upgrades it to X
request lock in LOCK_X|LOCK_REC_NOT_GAP mode on row 2:
// -> creates a new lock_t for LOCK_X|LOCK_REC_NOT_GAP mode (because we
// don't have any after we've upgraded!) and sets bit for 2
request lock in LOCK_S mode on row 2:
// -> notices that we already have LOCK_X|LOCK_REC_NOT_GAP on the row 2,
// so it upgrades it to X
    ...etc...etc..

Each iteration of the loop creates a new lock_t struct, and in the end we
have a lot (one for each record!) of LOCK_X locks, each with single bit
set in the bitmap. Soon we run out of space for lock_t structs.

If we create LOCK_GAP instead of lock upgrading, the above scenario works
like the following:

// -> creates new lock_t for LOCK_X|LOCK_REC_NOT_GAP mode and sets bit for
// 1
request lock in LOCK_S mode on row 1:
// -> notices that we already have LOCK_X|LOCK_REC_NOT_GAP on the row 1,
// so it creates LOCK_S|LOCK_GAP only and sets bit for 1
request lock in LOCK_X|LOCK_REC_NOT_GAP mode on row 2:
// -> reuses the lock_t for LOCK_X|LOCK_REC_NOT_GAP by setting bit for 2
request lock in LOCK_S mode on row 2:
// -> notices that we already have LOCK_X|LOCK_REC_NOT_GAP on the row 2,
// so it reuses LOCK_S|LOCK_GAP setting bit for 2

In the end we have just two locks per page, one for each mode:
LOCK_X|LOCK_REC_NOT_GAP and LOCK_S|LOCK_GAP.
Another benefit of this solution is that it avoids not-entirely
const-correct, (and otherwise looking risky) "upgrading".

The fix was ported from
mysql/mysql-server@bfba840dfa7794b988c59c94658920dbe556075d
mysql/mysql-server@75cefdb1f73b8f8ac8e22b10dfb5073adbdfdfb0

Reviewed by: Marko Mäkelä

Author: midenok
Author Date: 2023-07-03 19:51:03 UTC

Cleanups

Author: Yuchen Pei
Author Date: 2023-07-03 02:04:46 UTC

MDEV-26137 force flush?

Author: Yuchen Pei
Author Date: 2023-06-23 07:10:01 UTC

MDEV-31524 Fixing spider table param / variable overriding

The existing (incorrect) overriding mechanism is:

Non-minus-one var value overrides table param overrides default value.

Before MDEV-27169, unspecified var value is -1. So if the user sets
both the var to be a value other than -1 and the table param, the var
value will prevail, which is incorrect.

After MDEV-27169, unspecified var value is default value. So if the
user does not set the var but sets the table param, the default value
will prevail, which is even more incorrect.

This patch fixes it so that table param, if specified, always
overrides var value, and the latter if not specified or set to -1,
falls back to the default value

We achieve this by replacing all such overriding in spd_param.cc with
macros that override in the correct way, and removing all the
"overriding -1" lines involving table params in
spider_set_connect_info_default() except for those table params not
defined as sysvar/thdvar in spd_params.cc

We also introduced macros for non-overriding sysvar and thdvar, so
that the code is cleaner and less error-prone

In server versions where MDEV-27169 has not been applied, we also
backport the patch, that is, replacing -1 default values with real
default values

In server versions where MDEV-28006 has not been applied, we do the
same for udf params

Author: Rex Johnston
Author Date: 2023-06-27 04:51:10 UTC

MDEV-28622 Item_subselect eliminated flag set but Item still evaluated/used.

Subquery elimination by optimizer not taken into account elsewhere.

Author: Sergey Petrunia
Author Date: 2023-06-29 08:48:04 UTC

MDEV-31577: Make ANALYZE FORMAT=JSON print innodb stats

First implementation.

ANALYZE FORMAT=JSON_EXT now has table.r_engine_stats which has the
engine statistics. Only non-zero members are printed.

Internally: EXPLAIN data structure Explain_table_acccess now has a
pointer to the handler object. It will read the stats when producing
JSON output.
(TODO: are we ready to commit to the "EXPLAIN data structure requires
that tables used in the query still exist when output is printed") ?

Author: Yuchen Pei
Author Date: 2023-06-29 08:18:57 UTC

MDEV-31524 Further fixes of the params.

ha_part.test hangs at spider_copy_tables...

Author: Marko Mäkelä
Author Date: 2023-06-29 05:45:48 UTC

fixup! 056c83cc8f9551aa861dd9a3327584c8790562cd

Author: Yuchen Pei
Author Date: 2023-06-28 04:25:53 UTC

MDEV-31421 Fix spider test cleanup

This fixes mdev_26541.test, and the new clean_up_spider.inc will be
useful for other tests where part of deinit_spider does not apply,
e.g. those testing spider initialisation only.

Author: Yuchen Pei
Author Date: 2023-06-13 09:56:51 UTC

MDEV-22979 MDEV-27233 MDEV-28218 Fixing spider init bugs

Fix spider init bugs (MDEV-22979, MDEV-27233, MDEV-28218) while
preventing regression on old ones (MDEV-30370, MDEV-29904)

Two things are changed:

First, Spider initialisation is made fully synchronous, i.e. it no
longer happens in a background thread. Adapted from the original fix
by nayuta for MDEV-27233. This change itself would cause failure when
spider is initialised early, by plugin-load-add, due to dependency on
Aria and udf function creation, which are fixed in the second and
third parts below. Requires SQL Service, thus porting earlier versions
requires MDEV-27595

Second, if spider is initialised before udf_init(), create udf by
inserting into `mysql.func`, otherwise do it by `CREATE FUNCTION` as
usual. This change may be generalised in MDEV-31401.

Also factor out some clean-up queries from deinit_spider.inc for use
of spider init tests.

A minor caveat is that early spider initialisation will fail if the
server is bootstrapped for the first time, due to missing `mysql`
database which needs to be created by the bootstrap script.

Author: Yuchen Pei
Author Date: 2023-06-28 04:25:53 UTC

MDEV-31421 Fix spider test cleanup

This fixes mdev_26541.test, and the new clean_up_spider.inc will be
useful for other tests where part of deinit_spider does not apply,
e.g. those testing spider initialisation only.

Author: Yuchen Pei
Author Date: 2023-06-13 09:56:51 UTC

MDEV-22979 MDEV-27233 MDEV-28218 Fixing spider init bugs

Fix spider init bugs (MDEV-22979, MDEV-27233, MDEV-28218) while
preventing regression on old ones (MDEV-30370, MDEV-29904)

Two things are changed:

First, Spider initialisation is made fully synchronous, i.e. it no
longer happens in a background thread. Adapted from the original fix
by nayuta for MDEV-27233. This change itself would cause failure when
spider is initialised early, by plugin-load-add, due to dependency on
Aria and udf function creation, which are fixed in the second and
third parts below. Requires SQL Service, thus porting earlier versions
requires MDEV-27595

Second, if spider is initialised before udf_init(), create udf by
inserting into `mysql.func`, otherwise do it by `CREATE FUNCTION` as
usual. This change may be generalised in MDEV-31401.

Also factor out some clean-up queries from deinit_spider.inc for use
of spider init tests.

A minor caveat is that early spider initialisation will fail if the
server is bootstrapped for the first time, due to missing `mysql`
database which needs to be created by the bootstrap script.

Author: Yuchen Pei
Author Date: 2023-06-13 09:56:51 UTC

MDEV-22979 MDEV-27233 MDEV-28218 Fixing spider init bugs

Fix spider init bugs (MDEV-22979, MDEV-27233, MDEV-28218) while
preventing regression on old ones (MDEV-30370, MDEV-29904)

Two things are changed:

First, Spider initialisation is made fully synchronous, i.e. it no
longer happens in a background thread. Adapted from the original fix
by nayuta for MDEV-27233. This change itself would cause failure when
spider is initialised early, by plugin-load-add, due to dependency on
Aria and udf function creation, which are fixed in the second and
third parts below. Requires SQL Service, thus porting earlier versions
requires MDEV-27595

Second, if spider is initialised before udf_init(), create udf by
inserting into `mysql.func`, otherwise do it by `CREATE FUNCTION` as
usual. This change may be generalised in MDEV-31401.

Also factor out some clean-up queries from deinit_spider.inc for use
of spider init tests.

A minor caveat is that early spider initialisation will fail if the
server is bootstrapped for the first time, due to missing `mysql`
database which needs to be created by the bootstrap script.

Author: Yuchen Pei
Author Date: 2023-06-28 04:25:53 UTC

MDEV-31421 Fix spider test cleanup

This fixes mdev_26541.test, and the new clean_up_spider.inc will be
useful for other tests where part of deinit_spider does not apply,
e.g. those testing spider initialisation only.

Author: Yuchen Pei
Author Date: 2023-06-13 09:56:51 UTC

MDEV-22979 MDEV-27233 MDEV-28218 Fixing spider init bugs

Fix spider init bugs (MDEV-22979, MDEV-27233, MDEV-28218) while
preventing regression on old ones (MDEV-30370, MDEV-29904)

Two things are changed:

First, Spider initialisation is made fully synchronous, i.e. it no
longer happens in a background thread. Adapted from the original fix
by nayuta for MDEV-27233. This change itself would cause failure when
spider is initialised early, by plugin-load-add, due to dependency on
Aria and udf function creation, which are fixed in the second and
third parts below. Requires SQL Service, thus porting earlier versions
requires MDEV-27595

Second, if spider is initialised before udf_init(), create udf by
inserting into `mysql.func`, otherwise do it by `CREATE FUNCTION` as
usual. This change may be generalised in MDEV-31401.

Also factor out some clean-up queries from deinit_spider.inc for use
of spider init tests.

A minor caveat is that early spider initialisation will fail if the
server is bootstrapped for the first time, due to missing `mysql`
database which needs to be created by the bootstrap script.

Author: Yuchen Pei
Author Date: 2023-06-28 04:25:53 UTC

MDEV-31421 Fix spider test cleanup

This fixes mdev_26541.test, and the new clean_up_spider.inc will be
useful for other tests where part of deinit_spider does not apply,
e.g. those testing spider initialisation only.

Author: Yuchen Pei
Author Date: 2023-06-28 04:25:53 UTC

MDEV-31421 Fix spider test cleanup

This fixes mdev_26541.test, and the new clean_up_spider.inc will be
useful for other tests where part of deinit_spider does not apply,
e.g. those testing spider initialisation only.

Author: Yuchen Pei
Author Date: 2023-06-28 04:25:53 UTC

MDEV-31421 Fix spider test cleanup

This fixes mdev_26541.test, and the new clean_up_spider.inc will be
useful for other tests where part of deinit_spider does not apply,
e.g. those testing spider initialisation only.

Author: Yuchen Pei
Author Date: 2023-06-28 04:25:53 UTC

MDEV-31421 Fix spider test cleanup

This fixes mdev_26541.test, and the new clean_up_spider.inc will be
useful for other tests where part of deinit_spider does not apply,
e.g. those testing spider initialisation only.

Author: Yuchen Pei
Author Date: 2023-01-03 05:24:04 UTC

MDEV-29447 MDEV-26285 MDEV-31338 Refactor spider_db_mbase_util::open_item_func

spider_db_mbase_util::open_item_func() is a monster function.
It is difficult to maintain while it is expected that we need to
modify it when a new SQL function or a new func_type is added.

We split the function into two distinct functions: one handles the
case of str != NULL and the other handles the case of str == NULL.

This refactoring was done in a conservative way because we do not
have comprehensive tests on the function.

It also fixes MDEV-29447 and MDEV-31338 where field items that are
arguments of a func item may be used before created / initialised.

Note this commit is adapted from a patch by Nayuta for MDEV-26285.

Author: Yuchen Pei
Author Date: 2023-06-28 02:22:56 UTC

MDEV-30542 Fixing spider/bugfix.self_reference_multi

The server needs to have a unique name

Author: Yuchen Pei
Author Date: 2023-06-08 07:35:14 UTC

MDEV-26137 Improve import tablespace workflow.

Allow ALTER TABLE ... IMPORT TABLESPACE without creating the table
followed by discarding the tablespace.

That is, assuming we want to import table t1 to t2, instead of

CREATE TABLE t2 LIKE t1;
ALTER TABLE t2 DISCARD TABLESPACE;
FLUSH TABLES t1 FOR EXPORT;
--copy_file $MYSQLD_DATADIR/test/t1.cfg $MYSQLD_DATADIR/test/t2.cfg
--copy_file $MYSQLD_DATADIR/test/t1.ibd $MYSQLD_DATADIR/test/t2.ibd
UNLOCK TABLES;
ALTER TABLE t2 IMPORT TABLESPACE;

We can simply do

FLUSH TABLES t1 FOR EXPORT;
--copy_file $MYSQLD_DATADIR/test/t1.cfg $MYSQLD_DATADIR/test/t2.cfg
--copy_file $MYSQLD_DATADIR/test/t1.frm $MYSQLD_DATADIR/test/t2.frm
--copy_file $MYSQLD_DATADIR/test/t1.ibd $MYSQLD_DATADIR/test/t2.ibd
UNLOCK TABLES;
ALTER TABLE t2 IMPORT TABLESPACE;

We achieve this by creating a "stub" table in the second scenario
while opening the table, where t2 does not exist but needs to import
from t1. The "stub" table is similar to a table that is created but
then instructed to discard its tablespace.

We include tests with various row formats, encryption, with indexes
and auto-increment.

Signed-off-by: Yuchen Pei <ycp@mariadb.com>

Author: Yuchen Pei
Author Date: 2023-06-13 09:56:51 UTC

MDEV-22979 MDEV-27233 MDEV-28218 Fixing spider init bugs

Fix spider init bugs (MDEV-22979, MDEV-27233, MDEV-28218) while
preventing regression on old ones (MDEV-30370, MDEV-29904)

Two things are changed:

First, Spider initialisation is made fully synchronous, i.e. it no
longer happens in a background thread. Adapted from the original fix
by nayuta for MDEV-27233. This change itself would cause failure when
spider is initialised early, by plugin-load-add, due to dependency on
Aria and udf function creation, which are fixed in the second and
third parts below. Requires SQL Service, thus porting earlier versions
requires MDEV-27595

Second, if spider is initialised before udf_init(), create udf by
inserting into `mysql.func`, otherwise do it by `CREATE FUNCTION` as
usual. This change may be generalised in MDEV-31401.

Also factor out some clean-up queries from deinit_spider.inc for use
of spider init tests.

A minor caveat is that early spider initialisation will fail if the
server is bootstrapped for the first time, due to missing `mysql`
database which needs to be created by the bootstrap script.

Author: Yuchen Pei
Author Date: 2023-01-03 05:24:04 UTC

MDEV-29447 MDEV-26285 MDEV-31338 Refactor spider_db_mbase_util::open_item_func

spider_db_mbase_util::open_item_func() is a monster function.
It is difficult to maintain while it is expected that we need to
modify it when a new SQL function or a new func_type is added.

We split the function into two distinct functions: one handles the
case of str != NULL and the other handles the case of str == NULL.

This refactoring was done in a conservative way because we do not
have comprehensive tests on the function.

It also fixes MDEV-29447 and MDEV-31338 where field items that are
arguments of a func item may be used before created / initialised.

Note this commit is adapted from a patch by Nayuta for MDEV-26285.

Author: Yuchen Pei
Author Date: 2023-01-03 05:24:04 UTC

MDEV-29447 MDEV-26285 MDEV-31338 Refactor spider_db_mbase_util::open_item_func

spider_db_mbase_util::open_item_func() is a monster function.
It is difficult to maintain while it is expected that we need to
modify it when a new SQL function or a new func_type is added.

We split the function into two distinct functions: one handles the
case of str != NULL and the other handles the case of str == NULL.

This refactoring was done in a conservative way because we do not
have comprehensive tests on the function.

It also fixes MDEV-29447 and MDEV-31338 where field items that are
arguments of a func item may be used before created / initialised.

Note this commit is adapted from a patch by Nayuta for MDEV-26285.

Author: Yuchen Pei
Author Date: 2023-01-03 05:24:04 UTC

MDEV-29447 MDEV-26285 MDEV-31338 Refactor spider_db_mbase_util::open_item_func

spider_db_mbase_util::open_item_func() is a monster function.
It is difficult to maintain while it is expected that we need to
modify it when a new SQL function or a new func_type is added.

We split the function into two distinct functions: one handles the
case of str != NULL and the other handles the case of str == NULL.

This refactoring was done in a conservative way because we do not
have comprehensive tests on the function.

It also fixes MDEV-29447 and MDEV-31338 where field items that are
arguments of a func item may be used before created / initialised.

Note this commit is adapted from a patch by Nayuta for MDEV-26285.

Author: Yuchen Pei
Author Date: 2023-01-03 05:24:04 UTC

MDEV-29447 MDEV-26285 MDEV-31338 Refactor spider_db_mbase_util::open_item_func

spider_db_mbase_util::open_item_func() is a monster function.
It is difficult to maintain while it is expected that we need to
modify it when a new SQL function or a new func_type is added.

We split the function into two distinct functions: one handles the
case of str != NULL and the other handles the case of str == NULL.

This refactoring was done in a conservative way because we do not
have comprehensive tests on the function.

It also fixes MDEV-29447 and MDEV-31338 where field items that are
arguments of a func item may be used before created / initialised.

Note this commit is adapted from a patch by Nayuta for MDEV-26285.

Author: Yuchen Pei
Author Date: 2023-01-03 05:24:04 UTC

MDEV-29447 MDEV-26285 MDEV-31338 Refactor spider_db_mbase_util::open_item_func

spider_db_mbase_util::open_item_func() is a monster function.
It is difficult to maintain while it is expected that we need to
modify it when a new SQL function or a new func_type is added.

We split the function into two distinct functions: one handles the
case of str != NULL and the other handles the case of str == NULL.

This refactoring was done in a conservative way because we do not
have comprehensive tests on the function.

It also fixes MDEV-29447 and MDEV-31338 where field items that are
arguments of a func item may be used before created / initialised.

Note this commit is adapted from a patch by Nayuta for MDEV-26285.

Author: Yuchen Pei
Author Date: 2023-01-03 05:24:04 UTC

MDEV-29447 MDEV-26285 MDEV-31338 Refactor spider_db_mbase_util::open_item_func

spider_db_mbase_util::open_item_func() is a monster function.
It is difficult to maintain while it is expected that we need to
modify it when a new SQL function or a new func_type is added.

We split the function into two distinct functions: one handles the
case of str != NULL and the other handles the case of str == NULL.

This refactoring was done in a conservative way because we do not
have comprehensive tests on the function.

It also fixes MDEV-29447 and MDEV-31338 where field items that are
arguments of a func item may be used before created / initialised.

Note this commit is adapted from a patch by Nayuta for MDEV-26285.

Author: Yuchen Pei
Author Date: 2023-01-03 05:24:04 UTC

MDEV-29447 MDEV-26285 MDEV-31338 Refactor spider_db_mbase_util::open_item_func

spider_db_mbase_util::open_item_func() is a monster function.
It is difficult to maintain while it is expected that we need to
modify it when a new SQL function or a new func_type is added.

We split the function into two distinct functions: one handles the
case of str != NULL and the other handles the case of str == NULL.

This refactoring was done in a conservative way because we do not
have comprehensive tests on the function.

It also fixes MDEV-29447 and MDEV-31338 where field items that are
arguments of a func item may be used before created / initialised.

Note this commit is adapted from a patch by Nayuta for MDEV-26285.

Author: midenok
Author Date: 2023-06-22 12:58:43 UTC

Test: definite binlog positions

Author: Nikita Malyavin
Author Date: 2023-06-20 12:33:19 UTC

MDEV-27293 preview

Author: Rucha Deodhar
Author Date: 2023-06-20 11:25:38 UTC

MDEV-31477: Inconsistent handling while fetching values in json

Analysis:
JSON_KEY_VALUE() uses Json_path_extractor::extract() to reach to path and
extract values. One error it only returns true, but no error.
Fix:
report error when there is error in scanning json document.

Author: Rucha Deodhar
Author Date: 2023-06-20 10:51:57 UTC

MDEV-31477: Inconsistent handling while fetching values in json

Analysis:
When we get value in json_value(), if any error occurs while scanning the
json, it is not reported. Only true is returned.
Fix:
Report error along with returning true (error)

Author: Alexey Botchkov
Author Date: 2023-06-20 10:20:25 UTC

MDEV-22168 Supporting multiple engines with table partitioning

Author: Rucha Deodhar
Author Date: 2023-06-16 11:17:50 UTC

MDEV-31477: The JSON_KEY_VALUE function should print an error message
if json_doc is passed as a variable

Analysis:
JSON_KEY_VALUE() uses Json_path_extractor::extract() to reach to path and
extract values. One error it only returns true, but no error.
Fix:
report error when there is error in scanning json document.

Author: Sergei Golubchik
Author Date: 2023-06-19 14:20:21 UTC

MDEV-31474 KDF() function

KDF(key_str, salt [, {info | iterations} [, kdf_name [, width ]]])

kdf_name is hkdf (default) or pbkdf2_hmac.
width (in bits) can be any number divisible by 8,
by default it's taken from @@block_encryption_mode

Author: Yuchen Pei
Author Date: 2023-06-08 07:35:14 UTC

MDEV-26137 Improve import tablespace workflow.

Allow ALTER TABLE ... IMPORT TABLESPACE without creating the table
followed by discarding the tablespace.

That is, assuming we want to import table t1 to t2, instead of

CREATE TABLE t2 LIKE t1;
ALTER TABLE t2 DISCARD TABLESPACE;
FLUSH TABLES t1 FOR EXPORT;
--copy_file $MYSQLD_DATADIR/test/t1.cfg $MYSQLD_DATADIR/test/t2.cfg
--copy_file $MYSQLD_DATADIR/test/t1.ibd $MYSQLD_DATADIR/test/t2.ibd
UNLOCK TABLES;
ALTER TABLE t2 IMPORT TABLESPACE;

We can simply do

FLUSH TABLES t1 FOR EXPORT;
--copy_file $MYSQLD_DATADIR/test/t1.cfg $MYSQLD_DATADIR/test/t2.cfg
--copy_file $MYSQLD_DATADIR/test/t1.frm $MYSQLD_DATADIR/test/t2.frm
--copy_file $MYSQLD_DATADIR/test/t1.ibd $MYSQLD_DATADIR/test/t2.ibd
UNLOCK TABLES;
ALTER TABLE t2 IMPORT TABLESPACE;

We achieve this by creating a "stub" table in the second scenario
while opening the table, where t2 does not exist but needs to import
from t1. The "stub" table is similar to a table that is created but
then instructed to discard its tablespace.

We include tests with various row formats, encryption, with indexes
and auto-increment.

Signed-off-by: Yuchen Pei <ycp@mariadb.com>

Author: Vlad Lesin
Author Date: 2023-06-16 09:52:47 UTC

Two system variables are added to manage gcore dump location and debug it.

gcore_dump_dir - the directory, to which gcore dump files are generated,
                 by default they will be generated into data directory.

generate_gcore_dump - boolean variable for debug purpose to test gcore
                      dump generating functionality, generates gcore dump
                      on its value update.

Author: Vlad Lesin
Author Date: 2023-06-16 09:52:47 UTC

Two system variables are added to manage gcore dump location and debug it.

gcore_dump_dir - the directory, to which gcore dump files are generated,
                 by default they will be generated into data directory.

generate_gcore_dump - boolean variable for debug purpose to test gcore
                      dump generating functionality, generates gcore dump
                      on its value update.

Author: Sergey Petrunia
Author Date: 2023-06-19 08:27:51 UTC

Make the new tests --view-protocol friendly. Still don't pass.

Author: Rucha Deodhar
Author Date: 2023-05-25 10:15:43 UTC

MDEV-30145: JSON_TABLE: allow to retrieve the key when iterating on JSON
objects

Idea behind implementation:
We get the json object specified by the json path. Then, transform it into
key-value pairs by going over the json. Get each key-value pair
one-by-one and return the result.

Author: Alexander Barkov
Author Date: 2023-05-24 05:18:14 UTC

Basic support for timestamps with time zone.

Author: Daniel Black
Author Date: 2023-06-15 05:18:40 UTC

MDEV-27038 Custom configuration file procedure does not work with Docker Desktop for Windows 10+

Docker when mounting a configuration file into a Windows exposes the
file with permission 0777. These world writable files are ignored by
by MariaDB.

Add the access check such that filesystem RO or immutable file is
counted as sufficient protection on the file.

Test:
$ mkdir /tmp/src
$ vi /tmp/src/my.cnf
$ chmod 666 /tmp/src/my.cnf
$ mkdir /tmp/dst
$ sudo mount --bind /tmp/src /tmp/dst -o ro
$ ls -la /tmp/dst
total 4
drwxr-xr-x. 2 dan dan 60 Jun 15 15:12 .
drwxrwxrwt. 25 root root 660 Jun 15 15:13 ..
-rw-rw-rw-. 1 dan dan 10 Jun 15 15:12 my.cnf
$ mount | grep dst
tmpfs on /tmp/dst type tmpfs (ro,seclabel,nr_inodes=1048576,inode64)

strace client/mariadb --defaults-file=/tmp/dst/my.cnf

newfstatat(AT_FDCWD, "/tmp/dst/my.cnf", {st_mode=S_IFREG|0666, st_size=10, ...}, 0) = 0
access("/tmp/dst/my.cnf", W_OK) = -1 EROFS (Read-only file system)
openat(AT_FDCWD, "/tmp/dst/my.cnf", O_RDONLY|O_CLOEXEC) = 3

The one failing test, but this isn't a regression, just not a total fix:

$ chmod u-w /tmp/src/my.cnf
$ ls -la /tmp/src/my.cnf
-r--rw-rw-. 1 dan dan 18 Jun 16 10:22 /tmp/src/my.cnf
$ strace -fe trace=access client/mariadb --defaults-file=/tmp/dst/my.cnf
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
access("/etc/system-fips", F_OK) = -1 ENOENT (No such file or directory)
access("/tmp/dst/my.cnf", W_OK) = -1 EACCES (Permission denied)
Warning: World-writable config file '/tmp/dst/my.cnf' is ignored

Windows test (Docker Desktop ~4.21) which was the important one to fix:

dan@LAPTOP-5B5P7RCK:~$ docker run --rm -v /mnt/c/Users/danie/Desktop/conf:/etc/mysql/conf.d/:ro -e MARIADB_ROOT_PASSWORD=bob quay.io/m
ariadb-foundation/mariadb-devel:10.4-MDEV-27038-ro-mounts-pkgtest ls -la /etc/mysql/conf.d
total 4
drwxrwxrwx 1 root root 512 Jun 15 13:57 .
drwxr-xr-x 4 root root 4096 Jun 15 07:32 ..
-rwxrwxrwx 1 root root 43 Jun 15 13:56 myapp.cnf

root@a59b38b45af1:/# strace -fe trace=access mariadb
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
access("/etc/mysql/conf.d/myapp.cnf", W_OK) = -1 EROFS (Read-only file system)

Author: Yuchen Pei
Author Date: 2023-05-19 10:06:31 UTC

MDEV-22534 Decorrelate IN subquery

Transform

in (select inner_col' from inner_table where inner_col = outer_col)

to

, outer_col in (select inner_col', inner_col from inner_table)

Achieved by implementing Item_in_subselect::exists2in_processor(),
accompanied with comprehensive test coverage. Factored out common code
between the two transformations.

Caveat:

- Cannot recognise bad item mismatch in equalities that causes
  materialization to not materialize down the road

Author: Brandon Nesterenko
Author Date: 2023-06-14 14:21:22 UTC

MDEV-21322: Review note commit

Author: Sergey Petrunia
Author Date: 2023-06-14 10:00:51 UTC

MDEV-22534 Decorrelate IN subquery: Code cleanup

Author: Dmitry Shulga
Author Date: 2023-06-14 05:25:00 UTC

MDEV-5816: Stored programs: validation of stored program statements

The follow-up patch to check in mtr tests that recompilation of
a SP's instruction doesn't lead to eviction of SP from sp_cache.

This patch adds the debug keyword 'check_sp_cache_not_invalidated'
checked in sp_cache_flush_obsolete. In case this debug keyword
is set the macros DBUG_SUICIDE() called to cause test failure.

The function sp_cache_flush_obsolete() is called on opening
a stored routine. So setting this keyword before second execution
of some stored routine that supposed to cause recompilation of
SP's statement will guarantee that this stored routing not evicted
from sp_cache.

Suggested approach has one limitation - the statement
 CREATE/ALTER/DROP VIEW
forces invalidation of the whole sp_cache (by invoking the function
 sp_cache_invalidate()).
So, for those tests (actually, there are very small number of such tests)
that create/alter/drop a view before the second execution of some stored
routine, the debug keyword 'check_sp_cache_not_invalidated' isn't set.

The proposal to add some way a check that a stored routine is not force out
from sp_cache on re-parsing a failing statement of a stored routine was
done during reiew, that is the reason the proposed change has been formatted
as a separate patch.

Author: Vicențiu Ciorbaru
Author Date: 2023-06-13 16:39:23 UTC

Add test case for non-shadowed temporary sequence

Author: midenok
Author Date: 2023-06-13 12:12:53 UTC

Fix

Author: Dmitry Shulga
Author Date: 2023-06-13 11:19:53 UTC

MDEV-5816: Stored programs: validation of stored program statements

The follow-up patch to check in mtr tests that recompilation of
a SP's instruction doesn't lead to eviction of SP from sp_cache.

This patch adds the debug keyword 'check_sp_cache_not_invalidated'
checked in sp_cache_flush_obsolete. In case this debug keyword
is set the macros DBUG_SUICIDE() called to cause test failure.

The function sp_cache_flush_obsolete() is called on opening
a stored routine. So setting this keyword before second execution
of some stored routine that supposed to cause recompilation of
SP's statement will guarantee that this stored routing not evicted
from sp_cache.

Suggested approach has one limitation - the statement
 CREATE/ALTER/DROP VIEW
forces invalidation of the whole sp_cache (by invoking the function
 sp_cache_invalidate()).
So, for those tests (actually, there are very small number of such tests)
that create/alter/drop a view before the second execution of some stored
routine, the debug keyword 'check_sp_cache_not_invalidated' isn't set.

The proposal to add some way a check that a stored routine is not force out
from sp_cache on re-parsing a failing statement of a stored routine was
done during reiew, that is the reason the proposed change has been formatted as
separate patch.

Author: Yuchen Pei
Author Date: 2023-06-13 01:52:25 UTC

MDEV-31401 [demo] mysqld_server_started is no substitute for udf_initialized

...when it comes to decide whether to insert into mysql.func or create
function. The test udf_mysql_func_early fails.

Author: Sergei Golubchik
Author Date: 2023-06-09 09:44:32 UTC

ColumnStore 23.x compilation/build fixes

* enable warnings for gcc 12.x and 13.x
* work around compilation warnings with gcc 12.x and 13.x
* fix differences with srpm builds on fedora (--as-needed)

Author: Sergey Petrunia
Author Date: 2023-06-12 12:58:55 UTC

MDEV-31449: Assertion s->table->opt_range_condition_rows <= s->found_records

Fix a typo in make_join_statistics(): when updating statistics for
derived table, set s->table->... not "table->..."

Author: Daniel Black
Author Date: 2023-06-09 04:13:12 UTC

MDEV-31439: RPM conflicts with mysql-community-server

MariaDB-client is replacing mysql-community-client

MariaDB-Server obsoletes (*)
* mysql-errmsg (8.0.32) on error message files
* mysql-community-common (5.7) error message files, and /usr/share/mysql/*.sql init files and

MariaDB-common conflicts: (*)
* mysql-community-common (5.7) /usr/share/mysql/charsets
* mysql-common (8.0) /usr/share/mysql/charsets
* mysql-community-server (5.7) - /etc/my.cnf (omitted)

MariaDB-Server replacing mysql-community-server

Note *: remove on 11.0 merge as MariaDB installs to /usr/share/mariadb

Author: Marko Mäkelä
Author Date: 2023-06-08 12:34:24 UTC

Merge

Author: Yuchen Pei
Author Date: 2023-06-08 07:35:14 UTC

MDEV-26137 Improve import tablespace workflow.

Allow ALTER TABLE ... IMPORT TABLESPACE without creating the table
followed by discarding the tablespace.

That is, assuming we want to import table t1 to t2, instead of

CREATE TABLE t2 LIKE t1;
ALTER TABLE t2 DISCARD TABLESPACE;
FLUSH TABLES t1 FOR EXPORT;
--copy_file $MYSQLD_DATADIR/test/t1.cfg $MYSQLD_DATADIR/test/t2.cfg
--copy_file $MYSQLD_DATADIR/test/t1.ibd $MYSQLD_DATADIR/test/t2.ibd
UNLOCK TABLES;
ALTER TABLE t2 IMPORT TABLESPACE;

We can simply do

FLUSH TABLES t1 FOR EXPORT;
--copy_file $MYSQLD_DATADIR/test/t1.cfg $MYSQLD_DATADIR/test/t2.cfg
--copy_file $MYSQLD_DATADIR/test/t1.frm $MYSQLD_DATADIR/test/t2.frm
--copy_file $MYSQLD_DATADIR/test/t1.ibd $MYSQLD_DATADIR/test/t2.ibd
UNLOCK TABLES;
ALTER TABLE t2 IMPORT TABLESPACE;

We achieve this by creating a "stub" table in the second scenario
while opening the table, where t2 does not exist but needs to import
from t1. The "stub" table is similar to a table that is created but
then instructed to discard its tablespace.

We include tests with various row formats, encryption, with indexes
and auto-increment.

Signed-off-by: Yuchen Pei <yuchen.pei@mariadb.com>

Author: Marko Mäkelä
Author Date: 2023-06-07 15:07:40 UTC

Merge 10.5 into 10.6

Author: Yuchen Pei
Author Date: 2023-06-07 08:02:17 UTC

MDEV-22979 The udf hack for spider init queries

If spider is initialised before udf_init(), create udf by inserting
into `mysql.func`, otherwise do it by `CREATE FUNCTION` as usual.

Author: Marko Mäkelä
Author Date: 2023-06-07 06:43:38 UTC

WIP MDEV-30000: Trigger InnoDB checkpoint on backup

xtrabackup_backup_func(): Try to get InnoDB to flush the buffer pool
and wait for up to 15 seconds for it to take effect. This will reduce
the amount of log that will need to be processed both during --backup
and --prepare.

FIXME: If the connection between backup and the server is severed,
the 70100 handler will not run and the global variables will not be
restored.

FIXME: What to do if InnoDB is not enabled?

FIXME: Add a configuration parameter to enable this functionality
and to specify a timeout. Add some diagnostic output.

Author: Yuchen Pei
Author Date: 2023-05-25 02:52:38 UTC

MDEV-30435 MDEV-30981 Fix ubsan errors w.r.t. memcpy in spd_trx.cc

Extract the indexed string memcopy pattern in spd_trx.cc to a static
inline function.

Also updated the ubsan check in mdev_26541.test (h/t roel).

Author: Yuchen Pei
Author Date: 2023-05-25 02:52:38 UTC

MDEV-30435 MDEV-30981 Fix ubsan errors w.r.t. memcpy in spd_trx.cc

Extract the indexed string memcopy pattern in spd_trx.cc to a static
inline function.

Also updated the ubsan check in mdev_26541.test (h/t roel).

Author: Brandon Nesterenko
Author Date: 2023-03-08 20:49:32 UTC

MDEV-13915: STOP SLAVE takes very long time on a busy system

The problem is that a parallel replica would not immediately stop
running/queued transactions when issued STOP SLAVE. That is, it
allowed the current group of transactions to run, and sometimes the
transactions which belong to the next group could be started and run
through commit after STOP SLAVE was issued too, if the last group
had started committing. This would lead to long periods to wait for
all waiting transactions to finish.

This patch updates a parallel replica to try and abort immediately
and roll-back any ongoing transactions. The exception to this is any
transactions which are non-transactional (e.g. those modifying
sequences or non-transactional tables), and any prior transactions,
will be run to completion.

The specifics are as follows:

 1. A new stage was added to SHOW PROCESSLIST output for the SQL
Thread when it is waiting for a replica thread to either rollback or
finish its transaction before stopping. This stage presents as
“Waiting for worker thread to stop”

 2. Worker threads which error or are killed no longer perform GCO
cleanup if there is a concurrently running prior transaction. This
is because a worker thread scheduled to run in a future GCO could be
killed and incorrectly perform cleanup of the active GCO.

 3. Refined cases when the FL_TRANSACTIONAL flag is added to GTID
binlog events to disallow adding it to transactions which modify
both transactional and non-transactional engines when the binlogging
configuration allow the modifications to exist in the same event,
i.e. when using binlog_direct_non_trans_update == 0 and
binlog_format == statement.

 4. A few existing MTR tests relied on the completion of certain
transactions after issuing STOP SLAVE, and were re-recorded
(potentially with added synchronizations) under the new rollback
behavior.

Reviewed By:
============
Andrei Elkin <andrei.elkin@mariadb.com>

Author: Andrei
Author Date: 2023-06-05 16:31:32 UTC

MDEV-30421 arbitrary transaction dependency for optimistic parallel slave

This commit initiates a general framework to control data dependent transactions
on slave so that children of a particular dependency class (e.g defined
by the user as --parallel-ignore-db etc see SAMU-54) are to wait for
their parents' commits before they are allowed to start.

The data dependency condition is handled very similarly to one of
SPECULATE_WAIT, actually generalizing the latter as follows.
When two trx:s
                Ok-i -> Ok
(O - the notion of transaction from SAME-54, k-i, k - trx indexes in
binlog like gtid.seq_no)
depend say having updated the same "O" db), Ok has to
wait for Ok-i at the same execution point as a normal SPECULATE_WAIT
does. Afterward Ok registers to wait for ordered commit (by Tk-1 now)
and goes about its business.
The parent Ok-i normal workflow remains intact.

TODO:

This poc commit implies only one dependency class and the latter
simulated by "reusing" SET @@session.skip_parallel_replication=1
(as this commit is on the top of 10.4, rather that SAMU-54 branch).

- the limitation needs to be lifted
- the fact of trx belong to a specific data dependency class needs
  flagging in Gtid with a respective class' identifier
- SAMU-54 user interface to define dependencies needs some more
  thinking.
  E.g

  1. databases A,B listed in --parallel-ignore-db=A,B should represent
  two disjoint dependency classes (while of course in practice they
  may be not - through FK). If that's acceptable A and B should lead
  to different Gtid's dependency class identifiers.

  2. Dependency between trx:s are computable in ROW format to render
  void the purpose of --parallel-* rules/hints while the task of
  'computing' may need some design efforts.

Author: Brandon Nesterenko
Author Date: 2023-03-08 20:49:32 UTC

MDEV-13915: STOP SLAVE takes very long time on a busy system

The problem is that a parallel replica would not immediately stop
running/queued transactions when issued STOP SLAVE. That is, it
allowed the current group of transactions to run, and sometimes the
transactions which belong to the next group could be started and run
through commit after STOP SLAVE was issued too, if the last group
had started committing. This would lead to long periods to wait for
all waiting transactions to finish.

This patch updates a parallel replica to try and abort immediately
and roll-back any ongoing transactions. The exception to this is any
transactions which are non-transactional (e.g. those modifying
sequences or non-transactional tables), and any prior transactions,
will be run to completion.

The specifics are as follows:

 1. A new stage was added to SHOW PROCESSLIST output for the SQL
Thread when it is waiting for a replica thread to either rollback or
finish its transaction before stopping. This stage presents as
“Waiting for worker thread to stop”

 2. Worker threads which error or are killed no longer perform GCO
cleanup if there is a concurrently running prior transaction. This
is because a worker thread scheduled to run in a future GCO could be
killed and incorrectly perform cleanup of the active GCO.

 3. Refined cases when the FL_TRANSACTIONAL flag is added to GTID
binlog events to disallow adding it to transactions which modify
both transactional and non-transactional engines when the binlogging
configuration allow the modifications to exist in the same event,
i.e. when using binlog_direct_non_trans_update == 0 and
binlog_format == statement.

 4. A few existing MTR tests relied on the completion of certain
transactions after issuing STOP SLAVE, and were re-recorded
(potentially with added synchronizations) under the new rollback
behavior.

Reviewed By:
============
Andrei Elkin <andrei.elkin@mariadb.com>

Author: Brandon Nesterenko
Author Date: 2023-03-08 20:49:32 UTC

MDEV-13915: STOP SLAVE takes very long time on a busy system

The problem is that a parallel replica would not immediately stop
running/queued transactions when issued STOP SLAVE. That is, it
allowed the current group of transactions to run, and sometimes the
transactions which belong to the next group could be started and run
through commit after STOP SLAVE was issued too, if the last group
had started committing. This would lead to long periods to wait for
all waiting transactions to finish.

This patch updates a parallel replica to try and abort immediately
and roll-back any ongoing transactions. The exception to this is any
transactions which are non-transactional (e.g. those modifying
sequences or non-transactional tables), and any prior transactions,
will be run to completion.

The specifics are as follows:

 1. A new stage was added to SHOW PROCESSLIST output for the SQL
Thread when it is waiting for a replica thread to either rollback or
finish its transaction before stopping. This stage presents as
“Waiting for worker thread to stop”

 2. Worker threads which error or are killed no longer perform GCO
cleanup if there is a concurrently running prior transaction. This
is because a worker thread scheduled to run in a future GCO could be
killed and incorrectly perform cleanup of the active GCO.

 3. Refined cases when the FL_TRANSACTIONAL flag is added to GTID
binlog events to disallow adding it to transactions which modify
both transactional and non-transactional engines when the binlogging
configuration allow the modifications to exist in the same event,
i.e. when using binlog_direct_non_trans_update == 0 and
binlog_format == statement.

 4. A few existing MTR tests relied on the completion of certain
transactions after issuing STOP SLAVE, and were re-recorded
(potentially with added synchronizations) under the new rollback
behavior.

Reviewed By:
============
Andrei Elkin <andrei.elkin@mariadb.com>

Author: Sergey Petrunia
Author Date: 2023-06-05 13:40:08 UTC

MDEV-31403: Server crashes in st_join_table::choose_best_splitting

The code in choose_best_splitting() assumed that the join prefix is
in join->positions[].

This is not necessarily the case. This function might be called when
the join prefix is in join->best_positions[], too.
Follow the approach from best_access_path(), which calls this function:
pass the current join prefix as an argument,
"const POSITION *join_positions" and use that.

Author: tanruixiang
Author Date: 2022-06-16 07:05:35 UTC

MDEV-26182: Implement JSON_INTERSECT()

The idea is to have simple functions that the user can combine to produce
the exact result one wants, whether the user wants JSON object that has
common keys with another JSON object, or same key/value pair etc. So
making simpler function helps here.

We accomplish this by making three separate functions.
1) JSON_OBJECT_FILTER_KEYS(Obj, Arr_keys):
Put keys ( which are basically strings ) in hash, go over the object and
get key one by one. If the key is present in the hash,
add the key-value pair to result.

2) JSON_OBJECT_TO_ARRAY(Obj) : Create a string variable, Go over the json
object, and add each key value pair as an array into the result.

3) JSON_ARRAY_INTERSECT(arr1, arr2) :
Go over one of the json and add each item of the array
in hash (after normalizing each item). Go over the second array,
search the normalized item one by one in the hash. If item is found,
add it to the result.

Implementation Idea: Holyfoot ( Alexey Botchkov)
Author: tanruixiang and Rucha Deodhar

Author: Georg Richter
Author Date: 2023-06-05 11:42:26 UTC

docs test

Author: Lena Startseva
Author Date: 2023-05-31 04:57:45 UTC

MDEV-31003: Second execution for ps-protocol

This patch adds for "--ps-protocol" second execution
of queries "SELECT".
Also in this patch it is added ability to disable/enable
(--disable_ps2_protocol/--enable_ps2_protocol) second
execution for "--ps-prototocol" in testcases.

Author: Yuchen Pei
Author Date: 2023-06-05 02:17:50 UTC

MDEV-22979 [poc] init spider last and create udf by insertion

Author: Yuchen Pei
Author Date: 2023-06-02 00:48:18 UTC

MDEV-22534 fixing some ci complaint

Author: Rex Johnston
Author Date: 2023-06-01 03:38:56 UTC

MDEV-30944 Range_rowid_filter::fill() leaves file->keyread at MAX_KEY

Range_rowid_filter::fill() leaves keyread altered,
leading to assertion failure in join_tab->read_first_record().

Author: Sergey Petrunia
Author Date: 2023-06-01 11:06:06 UTC

MDEV-31380: Assertion `s->table->opt_range_condition_rows <= s->found_records' failed

LooseScan code set opt_range_condition_rows to be the

  MIN(loose_scan_plan->records, table->records)

totally ignoring possible quick range selects. If there was a quick
select $QUICK on another index with

  $QUICK->records < loose_scan_plan->records

this would create a situation where

   opt_range_condition_rows > $QUICK->records

which caused an assert.
Fixed by making opt_range_condition_rows to be the minimum #rows
of any quick select.

Author: Marko Mäkelä
Author Date: 2023-06-01 10:17:00 UTC

Merge 10.10 into 10.11

Author: Oleksandr "Sanja" Byelkin
Author Date: 2023-05-31 14:57:34 UTC

Fix of maturity

Author: Andrew Hutchings
Author Date: 2023-05-30 10:01:42 UTC

Fix COLUMNSTORE in Debian CI builds

Debian building tried to implicitly enable ColumnStore, but for this
to work, the boost/flex dependencies need to be there.

Also add `arm64` to the supported platforms for ColumnStore, that is
what it is identified as in Debian 11.

Author: Rex Johnston
Author Date: 2023-05-19 03:22:15 UTC

MDEV-31327 Range Histogram selectivity estimates added, not merged

When the optimizer is evaluating join order and estimating rows produced a join order, it loops through column constraints adding rather than merging selectivity estimates.

Author: Nikita Malyavin
Author Date: 2023-05-15 16:39:21 UTC

MDEV-30984 Online ALTER table is denied with non-informative error messages

Group all the checks in online_alter_check_supported().

There is now two groups of checks:
1. A technical availability of online, that is checked before open_tables,
and affects table_list->lock_type. It's supposed to be safe to make it
TL_READ even if COPY algorithm will fall back to not-online, since MDL is
SHARED_UPGRADEABLE anyway.
2. An 'online' availability for a COPY algorithm. It can be done as late as
just before the copy_data_between_tables call. The lock_type influence is
disclosed above, so the only other place it affects is
Alter_info::supports_lock, where `online` flag is only used to decide
whether to report the error at the inplace preparation stage. We'd want to
make that at the last resort, which is COPY preparation, if no algorithm is
chosen by the user. So it's event better now.

Some changes are required to the autoinc support detection, as the check
now happens after mysql_prepare_alter_table:
* alter_info->drop_list is empty
* instead, dropped columns are in tmp_set
* alter_info->create_list now has every field that's in the new table.
* the column definition's change.str will be nonnull whether the column
  remains in the new table (vs whether it was changed, as before).
  But it also has `field` field set.
* IF EXISTS doesn't have to be dealt anymore

This infers that the changes are now checked in more detail: a field's
definition shouldn't be changed, vs a field shouldn't be mentioned in
the CHANGE list, as it was before. This is reflected by the line 193 test.

Author: Yuchen Pei
Author Date: 2023-05-26 01:00:49 UTC

MDEV-22979 MDEV-27233 MDEV-28218 Fixing spider init bugs

We introduce a new set of synchronisation primitives ("query ready")
that are signaled when the server is ready to take queries, and make
spider initialisation use them instead of the primitives associated
with server start.

During spider initialisation, if the server is query ready, proceed
with the initialisation synchronously (requiring the sql
service). Otherwise, leave the init to the first sts bg thread as
usual.

When creating a spider handler before the spider init is done, if the
server is not query ready, just give up and return NULL. If the server
is query ready, then wait for a specific amount of time (5s) for the
spider init to be done, and on timeout give up and return NULL.

How this fixes / prevents various init bugs:

MDEV-27233 (spider installed and used in init file). Before -
spider_create_handler() called by read_init_file() waits for bg thread
to finish init, whereas the bg thread is waiting for server
start. After - spider init is run synchronously because the server is
query ready when read_init_file(). No funny business with concurrency.

MDEV-29904 (spider loaded with plugin-load-add). Before (before the
original patch to MDEV-27233 was reverted) - fully synchronous spider
init fails due to dependencies on Aria / acl init. After - spider init
is run async, and as soon as the server is query ready, the init
proceeds and succeeds.

MDEV-22979 (mysqld --bootstrap --plugin-load-add=ha_spider). Before -
bootstrap queries causes call to spider_create_handler(), which waits
for bg thread to finish init, whereas bg thread waits for server
start. After - spider init is run async, waiting for server to be
query ready. spider_create_hander() notices bg thread still trying to
init spider, and server is not query ready so it gives up.

MDEV-28218 (spider is loaded in a query after server start,
immediately before another query dropping a spider table). Before - bg
thread is created to init spider async, while the server proceeds to
the next query that tries to drop a spider system table. race
condition causes the situation where the server holds the mdl lock to
the table and waits for the bg thread in spider_create_handler(), and
the bg thread waiting for the mdl lock to create the table. After -
since server has already started, spider init is run synchronously,
thus no concurrency issues. Same applies to the variant of MDEV-28218
represented by mdev_28218_init_file where the queries are in an init
file.

Another variant of MDEV-28218 represented by mdev_28218_mixed loads
spider with plugin-load-add and executes the drop table query in an
init_file. Spider init is async because the server was not query
ready. As soon as the the server becomes query ready the server tries
to execute the drop table query. It waits on the init in
spider_create_handler(), but because of the deadlock it times out
after 5 seconds. The drop table query did not find any table, but
spider init then proceeds as it finally acquires the mdl lock, and
creates the table. The moral of the story is to advise users not to
mix plugin-load-add=ha_spider with init_file containing queries
related to spider system tables. Queries using spider engine to create
tables are still ok because there's no deadlock.

MDEV-30370 (mysqld --wsrep-recover --plugin-load-add=spider). The
timed wait in the patch for MDEV-30370 still applies, so it still
passes.

More on the design:

Compared to the server start primitives, the query ready primitives
are signaled earlier ("query ready point") to avoid unnecessary wait
and deadlocks.

The spider initialisation does not only require other plugins like
Aria to be initialised first, but also acl init (due to its creation
of udfs) as well as the creation of the `mysql` database (due to its
system tables being in this database). Thus the point where it can go
ahead with the initialisation should be after the bootstrap.

By the time the server can accept queries by reading from init files,
it can definitely accept all spider init queries. So the point of
spider initialisation can be before this point.

Looking at the lines between boostrap and reading init file, the most
natural position is just before the call to read_init_file(), where we
can also give the primitives a most meaningful name "query ready".

Author: Marko Mäkelä
Author Date: 2023-05-25 08:28:02 UTC

MDEV-31234 InnoDB does not free UNDO after the fix of MDEV-30671

trx_purge_truncate_rseg_history(): Add a parameter to specify if
the entire rollback segment is safe to be freed. If not, we may
still be able to invoke trx_undo_truncate_start() and free some pages,
but we will avoid leaking undo log pages that are not yet ready
to be processed. This fixes a regression that was introduced in
MDEV-30671.

trx_purge_free_segment(), trx_purge_truncate_rseg_history():
Replace some unreachable code with debug assertions.
A buffer-fix does prevent pages from being evicted
from the buffer pool; see buf_page_t::can_relocate().

trx_sys_t::any_active_transactions(): Separately count XA PREPARE
transactions.

srv_purge_should_exit(): Terminate slow shutdown if the history size
does not change and XA PREPARE transactions exist in the system.
This will avoid a hang of the test innodb.recovery_shutdown.

Author: Yuchen Pei
Author Date: 2023-05-25 02:52:38 UTC

MDEV-30435 MDEV-30981 Fix ubsan errors w.r.t. memcpy in spd_trx.cc

Extract the indexed string memcopy pattern in spd_trx.cc to a static
inline function.

Also updated the ubsan check in mdev_26541.test (h/t roel).

Author: Sergei Golubchik
Author Date: 2023-05-24 10:33:35 UTC

fix federatedx select pushdown after rebase

Author: Dmitry Shulga
Author Date: 2023-05-24 08:29:09 UTC

MDEV-14959: Control over memory allocated for SP/PS

Use sp_head::executed_counter only for debug output. The decision
to mark sp_head's mem_root as read only is performed based on
the fact that every SP instruction has been executed at least once.

Author: Oleksandr "Sanja" Byelkin
Author Date: 2023-05-24 07:38:18 UTC

Merge branch '10.6' into 10.8

Author: Yuchen Pei
Author Date: 2023-05-23 05:42:35 UTC

MDEV-31269 Fixing exists2in 2nd ps execution segfault

In the exists2in transformation, if 1) we are in a ps/sp execution and
2) the equalities picked out for the transformation intersect with the
temporary query arena free list, skip the transformation.

Further analysis:

Consider the following example:

--8<---------------cut here---------------start------------->8---
set optimizer_switch=default;
CREATE TABLE t1 (a INT);
CREATE TABLE t2 (b INT);
PREPARE st FROM "
SELECT * FROM t2
HAVING 0 IN (
  SELECT a FROM t1
  WHERE EXISTS (
    SELECT a FROM t1
    WHERE b = a
  )
)
";
EXECUTE st;
EXECUTE st;
drop table t1, t2;
--8<---------------cut here---------------end--------------->8---

1. During the JOIN::prepare() of the first execution, the Item_field referring to t2.b is replaced by an Item_ref
2. The item_ref is moved around in the exists2in transformation and subsequent optimizations
3. At the end of the 1st ps execution, the Item_ref is freed due to its creation in the ps execution as part of the cleanup
4. During the JOIN::prepare() of the second execution, it tries to restore the optimized version of the statement, in doing so it does a sanity check and causes a sigsegv when trying to access the freed Item_ref.

Why the problem does not occur with the transformation disabled:

- during step 1 above, the replacement also adds an item to the change_list
- during step 2 above, the optimizations cause the equality {{b = a}} to be moved around as a whole, thereby moving its {{args}} which is an {{Item **}} instead of the {{item *}}'s as a whole
- during step 3 above, the change is rolled back, so the {{Item **}} that is the args of the {{Item_func_eq}} goes from {{b (Item_ref) = a}} becomes {{b (Item_field) = a}}
- during step 4 above, there's no use-after-free in the restored optimized statment because it automatically contains the {{b (Item_field) = a}}.

Why we can't do the same with the transformation enabled:

- during step 2, we break the {{b = a}} into the outer_expr (b) and local_field (a), add the outer_expr to left_expr and local_field to the inner select item list. we cannot move the equality as a whole during this transformation.

Author: Yuchen Pei
Author Date: 2023-05-23 05:42:35 UTC

MDEV-31269 Fixing exists2in 2nd ps execution segfault

In the exists2in transformation, if 1) we are in a ps/sp execution and
2) the equalities picked out for the transformation intersect with the
temporary query arena free list, skip the transformation.

Further analysis:

Consider the following example:

--8<---------------cut here---------------start------------->8---
set optimizer_switch=default;
CREATE TABLE t1 (a INT);
CREATE TABLE t2 (b INT);
PREPARE st FROM "
SELECT * FROM t2
HAVING 0 IN (
  SELECT a FROM t1
  WHERE EXISTS (
    SELECT a FROM t1
    WHERE b = a
  )
)
";
EXECUTE st;
EXECUTE st;
drop table t1, t2;
--8<---------------cut here---------------end--------------->8---

1. During the JOIN::prepare() of the first execution, the Item_field referring to t2.b is replaced by an Item_ref
2. The item_ref is moved around in the exists2in transformation and subsequent optimizations
3. At the end of the 1st ps execution, the Item_ref is freed due to its creation in the ps execution as part of the cleanup
4. During the JOIN::prepare() of the second execution, it tries to restore the optimized version of the statement, in doing so it does a sanity check and causes a sigsegv when trying to access the freed Item_ref.

Why the problem does not occur with the transformation disabled:

- during step 1 above, the replacement also adds an item to the change_list
- during step 2 above, the optimizations cause the equality {{b = a}} to be moved around as a whole, thereby moving its {{args}} which is an {{Item **}} instead of the {{item *}}'s as a whole
- during step 3 above, the change is rolled back, so the {{Item **}} that is the args of the {{Item_func_eq}} goes from {{b (Item_ref) = a}} becomes {{b (Item_field) = a}}
- during step 4 above, there's no use-after-free in the restored optimized statment because it automatically contains the {{b (Item_field) = a}}.

Why we can't do the same with the transformation enabled:

- during step 2, we break the {{b = a}} into the outer_expr (b) and local_field (a), add the outer_expr to left_expr and local_field to the inner select item list. we cannot move the equality as a whole during this transformation.

Author: Marko Mäkelä
Author Date: 2023-05-23 14:20:35 UTC

Experiment: Remove handler::unlock_row() and friends

Failing test(s): innodb.innodb main.partition_innodb_semi_consistent innodb.innodb-semi-consistent innodb.innodb_lock_wait_timeout_1 main.concurrent_innodb_unsafelog main.unsafe_binlog_innodb innodb.create_table_insert_skip_locked rpl.rpl_unsafe_statements innodb.partition_locking innodb.skip_locked_nowait innodb.deadlock_wait_lock_race

Author: Marko Mäkelä
Author Date: 2023-05-23 12:32:20 UTC

Remove row_prebuilt_t::fetch_cache[]

Author: midenok
Author Date: 2023-05-22 16:11:21 UTC

MDEV-25495 AUTO argument to specify max number of partitions

Example:

  create table t1 (x int) with system versioning
  partition by system_time interval 1 hour auto 25;

Keeps 24 history partitions (and 1 current partition).

Note, MAX_SYM cannot be used for syntax expansion as this is function
name (sql_functions[] in lex.h)

fast_alter_partition_table() changes:

Auto-add like auto-drop now goes through REBUILD branch. MDL_EXCLUSIVE
is taken before mysql_change_partitions() like ALTER_PARTITION_ADD
branch does.

ha_partition::change_partitions() changes:

ADD PARTITION and DROP PARTITION in one command (as well as any other
alter partition operations) is not supported by the original code. The
patch partially solves this problem: ha_partition::change_partitions()
now can accept both PART_TO_BE_DROPPED and PART_TO_BE_ADDED states in
the partitions list. Originally change_partitions() was not used for
arbitrary drop of partitions, only REORGANIZE and COALESCE could be
processed by this call.

For REORGANIZE m_part_info->partitions contains new partitions set and
m_part_info->temp_partitions contains PART_TO_BE_REORGED
partitions. But we cannot use temp_partitions for dropping partitions
because they go through copy_partitions() phase (see how
m_reorged_parts initialized).

For COALESCE m_part_info->partitions in the beginning of the list
contains normal partitions that will remain when alter finishes, the
end of the list contains PART_REORGED_DROPPED partitions, so Step 4
can ignore them.

Step 4 for new_file_array preparation didn't skip PART_TO_BE_DROPPED
partitions in m_file. Now we increment orig_count for them.

Step 5 now properly iterates new_file_array in respect of skipping
PART_TO_BE_DROPPED while iterating m_part_info->partitions.

For full ADD+DROP support it would be needed to rework
prep_alter_part_table() as well. Now PART_TO_BE_DROPPED state is set
in vers_create_partitions() after prep_alter_part_table().

Author: Sergey Petrunia
Author Date: 2023-05-22 19:51:50 UTC

MDEV-31067: selectivity_from_histogram >1.0 for a DOUBLE_PREC_HB - V3-Fix1

Variant #3, fix for trivial errors.

Author: Oleg Smirnov
Author Date: 2023-05-19 09:53:39 UTC

MDEV-29630 WIP: remove index initialization from join_read_always_key()

Author: Teemu Ollakka
Author Date: 2023-04-17 13:04:01 UTC

MDEV-29293 MariaDB stuck on starting commit state

This is a backport from 10.5.

The problem seems to be a deadlock between KILL command execution
and BF abort issued by an applier, where:
* KILL has locked victim's LOCK_thd_kill and LOCK_thd_data.
* Applier has innodb side global lock mutex and victim trx mutex.
* KILL is calling innobase_kill_query, and is blocked by innodb
  global lock mutex.
* Applier is in wsrep_innobase_kill_one_trx and is blocked by
  victim's LOCK_thd_kill.

The fix in this commit removes the TOI replication of KILL command
and makes KILL execution less intrusive operation. Aborting the
victim happens now by using awake_no_mutex() and ha_abort_transaction().
If the KILL happens when the transaction is committing, the
KILL operation is postponed to happen after the statement
has completed in order to avoid KILL to interrupt commit
processing.

Notable changes in this commit:
* wsrep client connections's error state may remain sticky after
  client connection is closed. This error message will then pop
  up for the next client session issuing first SQL statement.
  This problem raised with test galera.galera_bf_kill.
  The fix is to reset wsrep client error state, before a THD is
  reused for next connetion.
* Release THD locks in wsrep_abort_transaction when locking
  innodb mutexes. This guarantees same locking order as with applier
  BF aborting.
* BF abort from MDL was changed to do BF abort on server/wsrep-lib
  side first, and only then do the BF abort on InnoDB side. This
  removes the need to call back from InnoDB for BF aborts which originate
  from MDL and simplifies the locking.
* Removed wsrep_thd_set_wsrep_aborter() from service_wsrep.h.
  The manipulation of the wsrep_aborter can be done solely on
  server side. Moreover, it is now debug only variable and
  could be excluded from optimized builds.
* Remove LOCK_thd_kill from wsrep_thd_LOCK/UNLOCK to allow more
  fine grained locking for SR BF abort which may require locking
  of victim LOCK_thd_kill. Added explicit call for
  wsrep_thd_kill_LOCK/UNLOCK where appropriate.
* Wsrep-lib was updated to version which allows external
  locking for BF abort calls.

Changes to MTR tests:
* Disable galera_bf_abort_group_commit. This test is going to
  be removed (MDEV-30855).
* Record galera_gcache_recover_manytrx as result file was incomplete.
  Trivial change.
* Make galera_create_table_as_select more deterministic:
  Wait until CTAS execution has reached MDL wait for multi-master
  conflict case. Expected error from multi-master conflict is
  ER_QUERY_INTERRUPTED. This is because CTAS does not yet have open
  wsrep transaction when it is waiting for MDL, query gets interrupted
  instead of BF aborted. This should be addressed in separate task.
* A new test galera_kill_group_commit to verify correct behavior
  when KILL is executed while the transaction is committing.

Co-authored-by: Seppo Jaakola <seppo.jaakola@iki.fi>
Co-authored-by: Jan Lindström <jan.lindstrom@galeracluster.com>
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>