The symtom of the bug was that check table on an S3 table when using
--s3_slave-ignore-updates=1 could print "9 when updating keyfile"

srv_do_purge(): In commit edde1f6e
when the de-facto 32-bit trx_sys_t::history_size() was replaced with
32-bit trx_sys.rseg_history_len, some more variables were changed
from ulint (size_t) to uint32_t.

The history list length is the number of committed transactions whose
undo logs are waiting to be purged. Each TRX_RSEG_HISTORY list is
storing the number of entries in a 32-bit field and each transaction
will occupy at least one undo log page. It is thinkable that the
length of each TRX_RSEG_HISTORY list may approach the maximum
representable number. The number cannot be exceeded, because the
rollback segment header is allocated from the same tablespace as
the undo log header pages it is pointing to, and because the page
numbers of a tablespace are stored in 32 bits. In any case, it is
possible that the total number of unpurged committed transactions
cannot be represented in 32 but 39 bits (corresponding to
128 rollback segments and undo tablespaces).

page_cur_insert_rec_low(): When checking for common bytes with
the preceding record, exclude the header bytes of next_rec
that could have been updated by this function.

The scenario where this caused corruption was an insert of
a node pointer record. The child page number was written as
0x203 but recovered as 0x103 because the n_owned field of next_rec
was changed from 1 to 2 before the comparison was invoked.

Backported fix from MariaDB 10.5

Test will fail if XML support is not compiled. This can happen if
XML support is disabled or if the libxml2 library is not installed.

This can happen if one doesn't have a working network connection when running
spider tests

MDEV-20888 : Galera test failure on galera.galera_pc_ignore_sb: 2013: Lost connection to MySQL server during query

Add debug info.

Add expected error.

MDEV-18283 : Galera test failure on galera.GCF-1081

Remove tests.

Commit introduces automatic detection which supported
Perl MariaDB DBI driver is available:

 * DBD::mysql
 * DBD::MariaDB

If nothing is then bail out and die

Current Detection prefers Perl DBD:MariaDB driver.

This is mainly for older Linux distros or Windows which does not
have Perl DBD:MariaDB packaged or does not want to use Perl cpan command.

Improve and add more languages for the ERROR 1476: Foreign Server
already exists.

When reading the man page of e.g. 'mysql' on a system with MariaDB
installed one would actually see the man page of 'mariadb'. However the
man page had no indication of the page being for 'mariadb', which was
confusing for users.

Fix this by updating the man page title lines to use mariadb-* instead
of mysql* for MariaDB binaries that are drop-in replacements for MySQL
equivalents, indicating that the commands are actually of the MariaDB
version.

In long term, all the commands in man pages should be replaced by their
MariaDB counterparts. Update the title lines as a start, and only those
that exist as symlinks to their MariaDB counterparts.

Before:

    man mariadb-upgrade | head -n 1
    MYSQL_UPGRADE(1) ...

After:

    man mariadb-upgrade | head -n 1
    MARIADB-UPGRADE(1) ...

All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer Amazon Web
Services, Inc.

Cause: a copy of the joined TABLE_LIST is created during multi_update::prepare
and TABLE::pos_in_table_list of the tables are set to point to the new
TABLE_LIST object. This prevents some optimization steps to perform correctly.
Solution: do not update pos_in_table_list during multi_update::prepare

MDEV-14642 Assertion 'table->s->db_create_options == part_table->s->db_create_options' failed in compare_table_with_partition

When trying to execute ALTER TABLE EXCHANGE PARTITION with different
definitions, assertion

    table->s->db_create_options == part_table->s->db_create_options

failed in compare_table_with_partition().

However, this execution should not be allowed since executing
'exchange partition' requires the identical structure of the two tables.

To fix the problem, I deleted the assertion code and added code that
returns an error that indicates tables have different definitions.

Reviewed By: Nayuta Yanagisawa

commit 84984b79 is null-merged

This commit sends a flag indicating the presence of the "--bypass"
option from the donor node to the joiner nodes during rsync IST,
because without such a flag it is impossible to distinguish IST
from the SST on the joiner nodes (in IST/SST scripts, because the
"--bypass" option is still not passed to scripts from server code).
Specifically, this fixes an issue with binary logs disappearing
after IST (via rsync). There are also changes to diagnostic messages
here that will make it easier to diagnose script-related problems
in the future when debugging and when checking the logs. This commit
also adds more robust signal handlers - to handle exceptions during
script execution. These handlers won't mask some crashes and it
also unifies exit codes between different scripts. These changes
have already been helpful to debugging "bypass" flag handling.

This commit fixes an issue with IST handling in
version 10.9 which is a regression after MDEV-26971
and related to trying to get a non-existent "total"
tag on the IST branch (this tag is only defined in
SST mode).

We cannot permanently change bits in read_partitions in the middle of
processing because ha_rnd_init()/ha_rnd_end() depends on that.

prefer if/skip over require
(works better with debugging, not affected by query log)

followup for c9b5a053

This reverts commit 17e0f522.

Function wsrep_read_only_option was already removed in commit
d54bc3c0 because it could cause race condition on variable
opt_readonly so that value OFF can become permanent.
Removed function again and added test case. Note that writes
to TEMPORARY tables are still allowed when read_only=ON.

same as MDEV-26412, but in CREATE...SELECT.
fix: apply 39feab3c to create rule too.

The counter srv_stats.key_rotation_list_length is never updated, and
therefore Innodb_encryption_key_rotation_list_length will always be 0.

The view INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION comes close
to reporting this information.