After d7d3ad69 we should use KILL_CONNECTION_HARD to interrupt
debug_sync waits. Test case uses debug_sync and then disconnects
connection from cluster.

The user XA commit execution branch was caught not have been covered
with MDEV-21953 fixes.

The XA involved deadlock is resolved now to apply the former fixes
pattern.
Along the fixes the following changes have been implemented.
- MDL lock attribute correction
- dissociation of the externally completed XA from the current
  thread's xid_state in the error branches
- cleanup_context() preseves the prepared XA
- wait_for_prior_commit() is relocated to satisfy both
  the binlog ON (log-slave-updates and skip-log-bin)
  and OFF slave execution branches.

- InnoDB fails to clear the freed ranges during truncation of innodb
undo log tablespace. During shutdown, InnoDB flushes the freed page
ranges and throws the out of bound error.

mtr_t::commit_shrink(): clear the freed ranges while doing undo
tablespace truncation

Since commit d7d3ad69, "hard" kill is
required to interrupt debug sync waits.
Affected the following tests:
 - galera_var_retry_autocommit,
 - galera_bf_abort_at_after_statement
 - galera_parallel_apply_3nodes
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

The condition is freed in sp_head::execute, after calling
ha_spider::reset. This commit partially reverts the change in commit
e954d9de, so that the condition is
always freed regardless of the wide_handler->sql_command, which will
prevent access to the freed condition later.
Signed-off-by: Yuchen Pei <yuchen.pei@mariadb.com>

Analysis:
When we skip level when path is found, it changes the state of the json
engine. This breaks the sequence for json_get_path_next() which is called at
the end to ensure json document is valid and leads to crash.
Fix:
Use json_scan_next() at the end to check if json document has correct
syntax (is valid).

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.

in normal execution, the item is wrapped in Item_func_conv_charset.

in --ps the whole is wrapped again in Item_direct_ref_to_item

allow real_item() to be called for const Item*,
remove casts in the code

"if not exists" must be stored in a separate read-only property

fix it for named constraints too

galera_gcache_recover and galera_gcache_recover_manytrx
  grepping on error log is not always successful as messages
  might be in different order or contain different values

galera_vote_sr
  We need to make sure required table creation has replicated
  as we use WSREP_ON=off

Fix `wsrep_init_gtid()` to avoid overwriting the domain id received
during state transfer.
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

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 problem was that federated engine does not support comparable rowids
which was not taken into account by semijoin code.

Fixed by checking that we don't use semijoin with tables that does not
support comparable rowids.

Other things:
- Fixed some typos in the code comments

The reason things fails in 10.5 and above is that test_quick_select()
returns -1 (impossible range) for empty tables if there are any
conditions attached.

This didn't happen in 10.4 as the cost for a range was more than for
a table scan with 0 rows and get_key_scan_params() did not create any
range plans and thus did not mark the range as impossible.

The code that checked the 'impossible range' conditions did not take
into account all cases of LEFT JOIN usage.

Adding an extra check if the table is used with an ON condition in case
of 'impossible range' fixes the issue.

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()