Currently @@version_compile_machine is used by mtr
to determine if the compiled executable is 32 or 64
bits.

We extend that logic by ensuring that if the DEFAUT_MACHINE
name doesn't have "64" in its string, "-64bits" is appended
to ensure these test pass.

trx_purge_rseg_get_next_history_log(): Fix a race condition that
was introduced in commit e46f76c9
(MDEV-15912). The buffer pool page contents must not be accessed
while not holding a page latch. The page latch was released by
mtr_t::commit().

This race resulted in an ASAN heap-use-after-poison during a stress test.

To avoid potential race conditions between concurrent access to
dict_table_t::freed_indexes, let us consistently use
dict_table_t::autoinc_mutex.

dict_table_remove_from_cache_low(): To avoid extensive hold time
of table->autoinc_mutex, unconditionally free the FTS data structures.

ha_innobase::check_if_supported_inplace_alter(): Do not invoke
innobase_table_is_empty() if the tablespace has been discarded.
That is, native ALTER TABLE in InnoDB will treat an empty table
in the same way as a tablespace whose tablespace has been discarded.
(Note: ALTER TABLE...ALGORITHM=COPY will fail if the tablespace
has been discarded.)

This fixes a crash that was introduced
in commit c7559747 (MDEV-19611).

TABLE_LIST::calc_md5(): Remove an untruthful const qualifier.

thd_get_query_start_data(): Pass empty_clex_str instead of
an uninitialized LEX_CSTRING.

Problem:
=======
The last AHI page for two indexes of an dropped table is being
freed at the same time by two threads. One thread frees the
table heap and other thread tries to access table heap again.
It leads to asan failure in btr_search_lazy_free().

Solution:
========
InnoDB uses autoinc_mutex to avoid the race condition
in btr_search_lazy_free()

The "$mysql_statedir/debian-$MAJOR_VER.flag" is not used by any
maintainer script ("$mysql_datadir/debian-$MAJOR_VER.flag" is used,
https://github.com/MariaDB/server/blob/10.6/debian/mariadb-server-10.6.postinst#L164).

See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985870

Fix also some minor typo.

Designated initializers were introduced in ISO/IEC 9899:1999 (C99),
but the C code base of MariaDB is supposed to be compatible with the
1990 version of the standard.

The InnoDB code based was switched from C to C++ in
MySQL 5.6 and MariaDB 10.0. C++ did not introduce syntax for
designated initializers until ISO/IEC 14882:2020.
Our C++ code base is still stuck with the 2011 or earlier version of
that standard.

Therefore, this check as well as the macro STRUCT_FLD are best removed.

This corrects the autobake on Stretch

Caused by commit 0268b871
and commit 3d16e0e1.

For very strange reasons (still a mistery) the above commits caused the
federatedx, archive and blackhole plugins to be missing in the
install location even though they where built in the build log.

This only occured on Stretch and not recent Ubuntu and Debian
distros.

The stretch autobake output contained:

dh_install: Cannot find (any matches for) "usr/lib/mysql/plugin/ha_archive.so" (tried in "." and "debian/tmp")
dh_install: mariadb-server-10.5 missing files: usr/lib/mysql/plugin/ha_archive.so
dh_install: Cannot find (any matches for) "usr/lib/mysql/plugin/ha_blackhole.so" (tried in "." and "debian/tmp")
dh_install: mariadb-server-10.5 missing files: usr/lib/mysql/plugin/ha_blackhole.so
dh_install: Cannot find (any matches for) "usr/lib/mysql/plugin/ha_federatedx.so" (tried in "." and "debian/tmp")
dh_install: mariadb-server-10.5 missing files: usr/lib/mysql/plugin/ha_federatedx.sodh_install: Cannot find (any matches for) "usr/lib/mysql/plugin/ha_archive.so" (tried in "." and "debian/tmp")
dh_install: mariadb-server-10.5 missing files: usr/lib/mysql/plugin/ha_archive.so
dh_install: Cannot find (any matches for) "usr/lib/mysql/plugin/ha_blackhole.so" (tried in "." and "debian/tmp")
dh_install: mariadb-server-10.5 missing files: usr/lib/mysql/plugin/ha_blackhole.so
dh_install: Cannot find (any matches for) "usr/lib/mysql/plugin/ha_federatedx.so" (tried in "." and "debian/tmp")
dh_install: mariadb-server-10.5 missing files: usr/lib/mysql/plugin/ha_federatedx.so

Remove commented out code, so that occasional reader is not confused.

It turns out, Field::set_notnull is required for a nullable I_S field.
Rework thread_pool_info.test to test request queueing in threadpool.

If --thread-pool-dedicated-listener is set, worker should not pick up
events. Dedicated listener constantly drains all events, thus polling
also from another thread makes no sense.

splitted permission setting to the 2 separate calls.
according to execute_process() doc, output from first command will be
piped to second which led to race and randomly lost suid bit from
auth_pam_tool.

Post push fix.

Added a missing WAIT_FOR signal line.

In MariaDB 10.6, ALTER TABLE t2 IMPORT TABLESPACE
will not remove the file t2.ibd on failure.

This fixes a failure of
./mtr --no-reorder innodb.import_corrupted innodb.innodb-agregate

foreign_push_index_error(): Fix a typo of 'match' that was introduced
in commit 5130f520 (MDEV-20480).

Thanks to Oli Sennhauser for reporting this.

Post-push fix for 10.5+.

The fix influence MDEV-14479. Before the fix
lock_rec_convert_impl_to_expl() did not create explicit lock if caller's
transaction owns found implicit lock(see MDEV-14479 for details). After the fix
lock_rec_convert_impl_to_expl() can create explicit lock under the above
conditions if the requested lock mode is not LOCK_REC_NOT_GAP. And that
is why we need to check if the table is X-locked before
lock_rec_convert_impl_to_expl() call.

The merge commit 4a259572
caused a test failure on Windows. The suppression regexp
needs to accept the backslash.

fil_invalid_page_access_msg(): Simplify the implementation
and invoke sql_print_error() directly.

fil_space_t::io(): Invoke fil_invalid_page_access_msg() only from
one location.

Analysis:
========
In case multi binlog truncation scenario debug sync points are in the
following order.

Two inserts are done on master as shown below.

INSERT INTO t1 VALUES (4, REPEAT("x", 4100)
commit_after_release_LOCK_after_binlog_sync

INSERT INTO t1 VALUES (5, REPEAT("x", 4100)
commit_after_release_LOCK_log

First insert debug sync ensures that transaction is synced to binlog and
not committed but it reached slave through semi sync.

Second insert debug sync ensures that transaction is synced to binlog and
not committed. It doesn't ensure that 'INSERT 5' reached slave.

Most of the times INSERT 5 reaches slave, hence when it is promoted as
master it sends 4,5 to slave. But occasionally 5 may not reach slave in
those cases post recovery master will have only 4. When row 6 is inserted
Master has 4-6 and Slave has 4,5,6.

This results in test failure.

Fix:
===
For the first insert use 'commit_before_get_LOCK_commit_ordered' debug sync
point, it will ensure that binlog was sent to slave and slave has
acknowledged the receipt. Now enable debug code such that when the next
transaction is written to binary log, dump thread will read and send it
across the network and notify the server to be get killed. Insert row 5
and wait for notification from dump thread. Kill the server. This ensures
that both 4 and 5 have reached the semi-sync slave.

Added a new test case:
Insert two rows on master such that first is present in master's binlog and
reached semi sync slave. Second insert should be flushed to binlog but not
sent to slave. Now crash and fail over to slave. The promoted master will send
the extra transaction to slave.

PageConverter::update_index_page(): Always validate the PAGE_INDEX_ID.
Failure to do so could cause a crash when iterating
secondary index pages. This was caught by the 10.4 test
innodb.full_crc32_import.