This patch allowed transformation of EXISTS subqueries into equivalent
IN predicands at the top level of WHERE conditions for multi-table UPDATE
and DELETE statements. There was no reason to prohibit the transformation
for such statements. The transformation provides more opportunities of
using semi-join optimizations.

Approved by Oleksandr Byelkin <sanja@mariadb.com>

Following tests do not test anymore what they intended to test

deleted:    suite/galera/t/MDEV-24143.test
deleted:    suite/galera/t/galera_bf_abort_get_lock.test

If WSREP_ON=ON do not allow GET_LOCK and RELEASE_LOCK functions.
Instead print clear error message.

This was an accidential deletion looking at an outdated list.

This is Kentoku's patch for MDEV-22979 (e6e41f04 + 22a00977),
which fixes 30370.

It changes the wait to a timed wait for the first sts thread, which
waits on server start to execute the init queries for spider. It also
flips the flag init_command to false when the sts thread is being
freed. With these changes the sts thread can check the flag regularly
and abort the init_queries when it finds out the init_command is
false. This avoids the deadlock that causes the problem in MDEV-30370.

It also fixes MDEV-22979 for 10.4, but not 10.5. I have not tested
higher versions for MDEV-22979.

A test has also been done on MDEV-29904 to avoid regression, given
MDEV-27233 is a similar problem and its patch caused the
regression. The test passes for 10.4-11.0.

However, this adhoc test only works consistently when placed in the
main testsuite. We should not place spider tests in the main suite, so
we do not include it in this commit. A patch for MDEV-27912 should fix
this problem and allow a proper test for MDEV-29904. See comments in
the jira ticket MDEV-30370/29904 for the adhoc testcase used for this
commit.

MDEV-26817 runtime error: index 24320 out of bounds for type 'json_string_char_classes [128] *and* ASAN: global-buffer-overflow on address ... READ of size 4 on SELECT JSON_VALID

protect from out-of-bound array access

it was already done in all other places, this one was the only one missed

disable bulk insert optimization if long uniques are used, because they
need to read the table (index_read) after every inserted now. And bulk
insert optimization might disable indexes.

bulk insert is already disabled in other cases when there are chances
that the table will be read duing the bulk insert.

plugin_vars_free_values() was walking plugin sysvars and thus
did not free memory of plugin PLUGIN_VAR_NOSYSVAR vars.

* change it to walk all plugin vars
* add the pluginname_ prefix to NOSYSVARS var names too,
  so that plugin_vars_free_values() would be able to find their
  bookmarks

MDEV-29294 Assertion `functype() == ((Item_cond *) new_item)->functype()' failed in Item_cond::remove_eq_conds on SELECT

Item_singlerow_subselect may be converted to Item_cond during
optimization. So there is a possibility of constructing nested
Item_cond_and or Item_cond_or which is not allowed (such
conditions must be flattened).
This commit checks if such kind of optimization has been applied
and flattens the condition if needed

There are no source code changes in this commit!
This is an empty follow-up commit for
  284ac6f2
to comment what was done, as the patch itself did not have
change comments.

Problems solved in this patch:

1. The function calc_hash_for_unique() erroneously takes into account
the string length, so equal strings (in terms of the collation)
with different lengths got different hash value.

For example:
- LATIN LETTER A             - 1 byte
- LATIN LETTER A WITH ACUTE  - 2 bytes

are equal in utf8_general_ci, but as their lengths
are different, calc_hash_for_unique() returned
different hash values.

2. calc_hash_for_unique() also erroneously used val_str()
result to calculate hashes. This may not be correct for
some data types, e.g. TIMESTAMP, as its string
value depends on the session environment (e.g. @@time_zone).

Change summary:

Instead of doing Item::val_str(), we should always call
Field::hash() of the underlying Field. It properly
handles both cases (equal strings with different
lengths, as well as tricky data types like TIMESTAMP).

Detailed change description:

Non-functional changes (make the code cleaner):

- Adding a helper class Hasher, to pass hash parts
  nr1 and nr2 through function arguments easier.
- Splitting virtual Field::hash() into non-virtual
  wrapper Field::hash() and virtual Field::hash_not_null().
  This helps to get rid of duplicate code handling SQL NULL,
  as it was equal in all Field_xxx implementations.
- Adding a new method THD::my_ok_with_recreate_info().

Actual fix changes (make new tables work properly):

- Adding a virtual method Item::hash_not_null()
  This helps to handle hashes on full fields (Item_field)
  and hashes on prefix fields (Item_func_left(Item_field))
  in a polymorphic way.
  Implementing overrides for Item_field and Item_func_left.

- Rewriting Item_func_hash::val_int() to use Item::hash_not_null(),
  instead of the combination of val_str() and alc_hash_for_unique().

Backward compatibility changes (make old tables work in the new server):

- Adding a new class Item_func_hash_mariadb_100403.
  Moving the old version of Item_func_hash::val_int()
  into Item_func_hash_mariadb_100403::val_int().
  The old class Item_func_hash_mariadb_100403 is still needed,
  to open old tables before upgrade is done.

- Adding TABLE_SHARE::old_long_hash_function() and
  handler::check_long_hash_compatibility() to test
  if a table is using an old hash function.

- Adding a helper method TABLE_SHARE::make_long_hash_func()
  to instantiate either Item_func_hash_mariadb_100403 (for old
  not upgraded tables) or Item_func_hash (for new tables).

Upgrade changes (make old tables upgrade in the new server properly):

Upgrading an old table to a new hash can be done using either
of these two statements:

  ALTER IGNORE TABLE t1 FORCE;
  REPAIR TABLE t1;

!!! These statements find and filter out erreneous duplicates!!!
The table after these statements will have less records
if there were erroneous duplicates (such and A and A WITH ACUTE).

The information about filtered out records is reported in both statements.

- Adding a new class Recreate_info to return out information
  about copied and duplucate rows from these functions:
  - mysql_alter_table()
  - mysql_recreate_table()
  - admin_recreate_table()
  This helps to print a warning during REPAIR:

MariaDB [test]> repair table mdev27653_100422_text;
+----------------------------+--------+----------+------------------------------------+
| Table                      | Op     | Msg_type | Msg_text                           |
+----------------------------+--------+----------+------------------------------------+
| test.mdev27653_100422_text | repair | Warning  | Number of rows changed from 2 to 1 |
| test.mdev27653_100422_text | repair | status   | OK                                 |
+----------------------------+--------+----------+------------------------------------+
2 rows in set (0.018 sec)

When built with ubsan and trying to load the spider plugin, the hidden
visibility of mysqld compiling flag causes ha_spider.so to be missing
the symbol ha_partition. This commit fixes that, as well as some
memcpy null pointer issues when built with ubsan.
Signed-off-by: Yuchen Pei <yuchen.pei@mariadb.com>

MDEV-29294 Assertion `functype() == ((Item_cond *) new_item)->functype()' failed in Item_cond::remove_eq_conds on SELECT

Item_singlerow_subselect may be converted to Item_cond during
optimization. So there is a possibility of constructing nested
Item_cond_and or Item_cond_or which is not allowed (such
conditions must be flattened).
This commit checks if such kind of optimization has been applied
and flattens the condition if needed

There are no source code changes in this commit!
This is an empty follow-up commit for
  284ac6f2
to comment what was done, as the patch itself did not have
change comments.

Problems solved in this patch:

1. The function calc_hash_for_unique() erroneously takes into account
the string length, so equal strings (in terms of the collation)
with different lengths got different hash value.

For example:
- LATIN LETTER A             - 1 byte
- LATIN LETTER A WITH ACUTE  - 2 bytes

are equal in utf8_general_ci, but as their lengths
are different, calc_hash_for_unique() returned
different hash values.

2. calc_hash_for_unique() also erroneously used val_str()
result to calculate hashes. This may not be correct for
some data types, e.g. TIMESTAMP, as its string
value depends on the session environment (e.g. @@time_zone).

Change summary:

Instead of doing Item::val_str(), we should always call
Field::hash() of the underlying Field. It properly
handles both cases (equal strings with different
lengths, as well as tricky data types like TIMESTAMP).

Detailed change description:

Non-functional changes (make the code cleaner):

- Adding a helper class Hasher, to pass hash parts
  nr1 and nr2 through function arguments easier.
- Splitting virtual Field::hash() into non-virtual
  wrapper Field::hash() and virtual Field::hash_not_null().
  This helps to get rid of duplicate code handling SQL NULL,
  as it was equal in all Field_xxx implementations.
- Adding a new method THD::my_ok_with_recreate_info().

Actual fix changes (make new tables work properly):

- Adding a virtual method Item::hash_not_null()
  This helps to handle hashes on full fields (Item_field)
  and hashes on prefix fields (Item_func_left(Item_field))
  in a polymorphic way.
  Implementing overrides for Item_field and Item_func_left.

- Rewriting Item_func_hash::val_int() to use Item::hash_not_null(),
  instead of the combination of val_str() and alc_hash_for_unique().

Backward compatibility changes (make old tables work in the new server):

- Adding a new class Item_func_hash_mariadb_100403.
  Moving the old version of Item_func_hash::val_int()
  into Item_func_hash_mariadb_100403::val_int().
  The old class Item_func_hash_mariadb_100403 is still needed,
  to open old tables before upgrade is done.

- Adding TABLE_SHARE::old_long_hash_function() and
  handler::check_long_hash_compatibility() to test
  if a table is using an old hash function.

- Adding a helper method TABLE_SHARE::make_long_hash_func()
  to instantiate either Item_func_hash_mariadb_100403 (for old
  not upgraded tables) or Item_func_hash (for new tables).

Upgrade changes (make old tables upgrade in the new server properly):

Upgrading an old table to a new hash can be done using either
of these two statements:

  ALTER IGNORE TABLE t1 FORCE;
  REPAIR TABLE t1;

!!! These statements find and filter out erreneous duplicates!!!
The table after these statements will have less records
if there were erroneous duplicates (such and A and A WITH ACUTE).

The information about filtered out records is reported in both statements.

- Adding a new class Recreate_info to return out information
  about copied and duplucate rows from these functions:
  - mysql_alter_table()
  - mysql_recreate_table()
  - admin_recreate_table()
  This helps to print a warning during REPAIR:

MariaDB [test]> repair table mdev27653_100422_text;
+----------------------------+--------+----------+------------------------------------+
| Table                      | Op     | Msg_type | Msg_text                           |
+----------------------------+--------+----------+------------------------------------+
| test.mdev27653_100422_text | repair | Warning  | Number of rows changed from 2 to 1 |
| test.mdev27653_100422_text | repair | status   | OK                                 |
+----------------------------+--------+----------+------------------------------------+
2 rows in set (0.018 sec)

When built with ubsan and trying to load the spider plugin, the hidden
visibility of mysqld compiling flag causes ha_spider.so to be missing
the symbol ha_partition. This commit fixes that, as well as some
memcpy null pointer issues when built with ubsan.
Signed-off-by: Yuchen Pei <yuchen.pei@mariadb.com>

Updated wsrep-lib to version in which server_state
wait_until_state() and sst_received() were changed to report
errors via return codes instead of throwing exceptions. Added
error handling accordingly.

Tested manually that failure in sst_received() which was
caused by server misconfiguration (unknown configuration variable
in server configuration) does not cause crash due to uncaught
exception.

MySQL 5.7.41 includes one InnoDB change
mysql/mysql-server@d2d6b2dd00f709bc528386009150d4bc726e25a0
that seems to be applicable to MariaDB Server 10.3 and 10.4.
Even though commit 5b9ee8d8
seems to have fixed sporadic failures on our CI systems, it is
theoretically possible that another race condition remained.

buf_flush_page_cleaner_coordinator(): In the final loop,
wait also for buf_get_n_pending_read_ios() to reach 0.
In this way, if a secondary index leaf page was read into the
buffer pool and ibuf_merge_or_delete_for_page() modified that
page or some change buffer pages, the flush loop would execute
until the buffer pool really is in a clean state.

This potential data corruption bug does not affect MariaDB Server 10.5
or later, thanks to commit b42294bc
which removed change buffer merges that are not explicitly requested.

If two high priority threads have lock conflict, we look at the
order of these transactions and honor the earlier transaction.
for_locking parameter in lock_rec_has_to_wait() has become
obsolete and it is now removed from the code .
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

The rather recent thd_need_ordering_with() function does not take
high priority transactions' order in consideration. Chaged this
funtion to compare also transaction seqnos and favor earlier transaction.
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

This commit contains only a mtr test for reproducing the issue in MDEV-29512
The actual fix will be pushed in wsrep-lib repository

The hanging in MDEV-29512 happens when binlog purging is attempted, and there is
one local BF aborted transaction waiting for commit monitor.

The test will launch two node cluster and enable binlogging with expire log days,
to force binlog purging to happen.
A local transaction is executed so that will become BF abort victim, and has advanced
to replication stage waiting for commit monitor for final cleanup (to mark position in innodb)
after that, applier is released to complete the BF abort and due to binlog configuration,
starting the binlog purging. This is where the hanging would occur, if code is buggy
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

Created mtr test for reproducing the crash

Developed actual fix for the issue.
Setting THD::system_thread_info.rpl_sql_info for replayer thread,
same way as it is handled for appliers.

Recorded test result, with the fix
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

Cluster conflict victim's THD is marked with wsrep_aborter.
THD::wsrep_aorter holds the thread ID of the hight priority tread,
which is currently carrying out BF aborting for this victim.

However, the BF abort operation is not always successful,
and in such case the wsrep_aborter mark should be removed.
In the old code, this wsrep_aborter resetting did not happen,
and this could lead to a situation where the sticky wsrep_aborter
mark prevents any further attempt to BF abort this transaction.

This commit fixes this issue, and resets wsrep_aborter after
unsuccesful BF abort attempt.
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

node->is_delete was incorrectly set to NO_DELETE for a set of operations.

In general we shouldn't rely on sql_command and look for more abstract ways
to control the behavior.

trg_event_map seems to be a suitable way. To mind replica nodes, it is ORed
with slave_fk_event_map, which stores trg_event_map when replica has
triggers disabled.

Signed-off-by: lilinjie <lilinjie@uniontech.com>

This only happens with 'timestamp_column IN (select ...)

The reason was a missing assignment in Item_cache_timestamp::cache_value()