The 10.5->10.6 merge commit 3bc98a4e casts the arg to an int16
pointer in set_extraction_flag_processor(). This matched the previous
commit c76eabfb where set_extraction_flag was changed to have int16 arg
instead of int.

The commit a5e4c349 for MDEV-29363 added a call to
set_extraction_flag_processor on IMMUTABLE_FL (MARKER_IMMUTABLE in 10.6).
The subsequent 10.5->10.6 merge f071b762 did not cast the flag
to int16 when merging this change.

The result is big-endian processors cleared the immutable
flag rather than set the flag, resulting in MDEV-29363
being unfixed on big-endian processors.

Was failing because innodb-log-file-buffering is a Linux/Windows only
variable.

This was introduced in MDEV-33787 to enforce O_DIRECT on Linux.

The functions called in blocks protected by this macro remain
undefined as of 11.5 c96b23f9

It's virtually empty now

Show::Column() was added in MDEV-19772
4156b1a2

handler::pre_calculate_checksum was added in MDEV-16249
be5c432a

get_negated() was introduced in MDEV-16707

sql_cache was moved to lex in MDEV-11953 in
de745ecf

{STRING|INT|REAL|DECIMAL|DATE}_ITEM were replaced with CONST_ITEM in
MDEV-14630 c20cd68e

MDEV-16246 was fixed long ago. And this macro was removed in other
versions too

handler::need_info_for_auto_inc() was added in MDEV-7720 / MDEV-7726
in commit dc17ac16

This macro is unused, and not in 11.5 c96b23f9

This macro is unused

The flag argument was added to handler::start_bulk_insert() in
the MDEV-539 commit
ca2cdaad

new_data is const since at least 2017: a05a610d

handler has can_use_for_auto_inc_init() since at latest 2017:
dc17ac16

HA_EXTRA_USE_CMP_REF is undefined, and remains so as of 11.5
c96b23f9

HA_EXTRA_STARTING_ORDERED_INDEX_SCAN was added latest 2018:
921c5e93

net has thd since 2015 in 56aa1998 for MDEV-6152

arg_count was protected since 2015 in commit
afa17734

unifdef -DSPIDER_HAS_HASH_VALUE_TYPE -m storage/spider/spd_* storage/spider/ha_spider.* storage/spider/hs_client/*

10.5 added contents of cmake/os/FreeBSD.cmake in c991efd9.
in the merge to 10.11, d002b1f5 removed this file.

In the past FreeBSD.cmake was removed in 5369df74
in the 10.11 branch as no remaining code was needed. The combination
of this and the merge lead to the the file being removed. My assumption is
this was a non-stable branch at the time.

The purpose of this patch is clang doesn't have /usr/local/lib in
the path. As such there are various depedency linkages that will fail.

For example pcre and libfmt.

os_file_log_maybe_unbuffered is now Linux only.

Aso the stat st structure only used in linux.

This avoids unused function/structure errors on FreeBSD.

In mariadb-backup --backup there are multiple mechanisms for ensuring that
a sufficient amount of the InnoDB write-ahead log (ib_logfile0) is being
copied at the end of the backup. The backup needs to include the latest
committed transaction. While further transaction commits are blocked by
BACKUP STAGE BLOCK_COMMIT, ongoing transactions may modify the database
contents and write log records. We were unnecessarily copying such log,
which would also cause further effort of rolling back incomplete
transactions after the backup is restored.

backup_wait_for_lsn(): Declare as static, and refactor some code
to separate functions backup_wait_for_lsn_low() and
backup_wait_timeout().

backup_wait_for_commit_lsn(): A new function to determine the current
LSN (within BACKUP STAGE BLOCK_COMMIT) and to wait for the log to be
copied until that. Invoked by BackupStages::stage_block_commit().

xtrabackup_backup_func(): Remove a condition that had already been
checked by a caller of backup_wait_timeout().

server_lsn_after_lock: Declare as a local variable in
BackupStages::stage_block_ddl().

log_copying_thread(), io_watching_thread(): Use metadata_last_lsn
instead of metadata_to_lsn as the stop condition.

BackupStages::stage_block_commit(): Ensure that the log tables
(in particular, mysql.general_log) will have been copied before
the BACKUP STAGE BLOCK_COMMIT is being followed by any further
SQL statements.

Reviewed by: Debarun Banerjee
Tested by: Matthias Leich

Reason:
=======
- During bootstrap, InnoDB shrinks the system tablespace while purge is
still active on system tablespace. This could lead to deadlock.

Fix:
====
Avoid System tablespace shrinking during bootstrap.
Move the shrinking logic of system tablespace after purge gets shutdown.

(Variant 4, with @@optimizer_adjust_secondary_key_costs, reuse in two
places, and conditions are replaced with equivalent simpler forms in two more)

In best_access_path(), ReuseRangeEstimateForRef-3,  the check
for whether
 "all used key_part_i used key_part_i=const"
was incorrect: it may produced a "NO" answer for cases when we
had:
 key_part1= const // some key parts are usable
 key_part2= value_not_in_join_prefix  //present but unusable
 key_part3= non_const_value // unusable due to gap in key parts.

This caused the optimizer to fail to apply ReuseRangeEstimateForRef
heuristics. The consequence is poor query plan choice when the index
in question has very skewed data distribution.

The fix is enabled if its @@optimizer_adjust_secondary_key_costs flag
is set.