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/*

In the bug report MDEV-32817 it occurred that the function
row_mysql_get_table_status() is outputting a fil_space_t*
as if it were a numeric tablespace identifier.

ib_push_warning(): Remove. Let us invoke push_warning_printf() directly.

innodb_decryption_failed(): Report a decryption failure and set the
dict_table_t::file_unreadable flag. This code was being duplicated in
very many places. We return the constant value DB_DECRYPTION_FAILED
in order to avoid code duplication in the callers and to allow tail calls.

innodb_fk_error(): Report a FOREIGN KEY error.

dict_foreign_def_get(), dict_foreign_def_get_fields(): Remove.
This code was being used in dict_create_add_foreign_to_dictionary()
in an apparently uncovered code path. That ib_push_warning() call
would pass the integer i+1 instead of a pointer to NUL terminated
string ("%s"), and therefore the call should have resulted in a crash.

dict_print_info_on_foreign_key_in_create_format(),
innobase_quote_identifier(): Add const qualifiers.

row_mysql_get_table_error(): Replaces row_mysql_get_table_status().
Display no message on DB_CORRUPTION; it should be properly reported at
the SQL layer anyway.

MDEV-33858 Assertion `(mem_root->flags & 4) == 0' fails on 2nd execution of PS with -DWITH_PROTECT_STATEMENT_MEMROOT=ON

Simply adding tests as the bug is fixed with a backport of MDEV-34447

The memory leak happened on second execution of a prepared statement
that runs UPDATE statement with correlated subquery in right hand side of
the SET clause. In this case, invocation of the method
  table->stat_records()
could return the zero value that results in going into the 'if' branch
that handles impossible where condition. The issue is that this condition
branch missed saving of leaf tables that has to be performed as first
condition optimization activity. Later the PS statement memory root
is marked as read only on finishing first time execution of the prepared
statement. Next time the same statement is executed it hits the assertion
on attempt to allocate a memory on the PS memory root marked as read only.
This memory allocation takes place by the sequence of the following
invocations:
 Prepared_statement::execute
  mysql_execute_command
   Sql_cmd_dml::execute
    Sql_cmd_update::execute_inner
     Sql_cmd_update::update_single_table
      st_select_lex::save_leaf_tables
       List<TABLE_LIST>::push_back

To fix the issue, add the flag SELECT_LEX::leaf_tables_saved to control
whether the method SELECT_LEX::save_leaf_tables() has to be called or
it has been already invoked and no more invocation required.

Similar issue could take place on running the DELETE statement with
the LIMIT clause in PS/SP mode. The reason of memory leak is the same as for
UPDATE case and be fixed in the same way.

From e735cf2ed7cefb2af36f10f3cb47dfc060789df3, the PCRE_INCLUDES
changed to PCRE_INCLUDE_DIRS for consistency.

The columnstore module depends on the old name.

Create a mapping for the columnstore submodule.

10.6+ fix for submodule is:
* https://github.com/mariadb-corporation/mariadb-columnstore-engine/pull/3304

Taking both the FreeBSD[1] and Alpine[1] patch concepts;

provide non-GLIBC definations for HMT_*.

Provide FreeBSD ASM base for __ppc_get_timebase.
On alternately use __builtin_ppc_get_timebase which is described
on https://gcc.gnu.org/onlinedocs/gcc/Basic-PowerPC-Built-in-Functions-Available-on-all-Configurations.html
an not depended on glibc/musl.

[1] https://github.com/freebsd/freebsd-ports/blob/15d22e1c70da81aaa5751ad0d82f92e9451c4d81/databases/mariadb106-server/files/patch-include_my__cpu.h
[2] https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/mariadb/ppc-remove-glibc-dep.patch

From https://github.com/freebsd/freebsd-ports/blob/15d22e1c70da81aaa5751ad0d82f92e9451c4d81/databases/mariadb106-server/files/patch-sql_mysqld.cc

Upstream the patch from: https://github.com/freebsd/freebsd-ports/blob/15d22e1c70da81aaa5751ad0d82f92e9451c4d81/databases/mariadb106-server/files/patch-mysys_crc32_crc32c.cc

even if pkg-config has it. otherwise build dependencies
aren't detected.

use pkg-config to find pcre2, if possible

rename PCRE_INCLUDES to use PKG_CHECK_MODULES naming, PCRE_INCLUDE_DIRS

Without the call to my_mutex_init, the mutex attributes
my_fast_mutexattr and my_errorcheck_mutexattr are uninitialized.

Linux tolerates this but FreeBSD doesn't (and segfaults).

We fix for all since the unit text should be testing the
standard mutexes of the system.

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.`

MySQL-Connector-Net casts SEQ_IN_INDEX to uint and will
raise an exception if the type is a System.Int64.

As we don't support a huge number of multi-columns in
an index reducing to a uint is sufficient to represent
all values and maintain compatibility with MySQL-Connector-Net.

This matches the type (uint) returned by MySQL-8.3 and 8.0.

Reviewer: Alexander Barkov <bar@mariadb.com>

It's possible that MDL conflict handling code is called more
than once for a transaction when:
- it holds more than one conflicting MDL lock
- reschedule_waiters() is executed,
which results in repeated attempts to BF-abort already aborted
transaction.
In such situations, it might be that BF-aborting logic sees
a partially rolled back transaction and erroneously decides
on future actions for such a transaction.

The specific situation tested and fixed is when a SR transaction
applied in the node gets BF-aborted by a started TOI operation.
It's then caught with the server transaction already rolled back,
but with no MDL locks yet released. This caused wrong state
detection for such a transaction during repeated MDL conflict
handling code execution.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

* Fixes galera.galera_bf_kill_debug test case.
* Enable galera_ssl_upgrade, galera_ssl_reload, galera_pc_bootstrap
* Add MDEV to disabled tests that miss it
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

Based on logs SST was started before donor reached
Primaty state. Add wait_conditions to make sure that
nodes reach Primary state before starting next node.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

generate consistent error messages,
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

For TOI events specifically we have a situation where in case of the
same error different nodes may generate different messages. This may
be for two reasons:
 - different locale setting between the current client session and
   server default (we can reasonably require server locales to be
   identical on all nodes, but user can change message locale for the
   session)
 - non-deterministic course of STATEMENT execution e.g. for ALTER TABLE

On the other hand we may reasonably expect TOI event failures since
they are executed after replication, so we must ensure that voting is
consistent. For that purpose error codes should be sufficiently unique
and deterministic for TOI event failures as DDLs normally deal with
a single object, so we can merely use MySQL error codes to vote on.

Notice that this problem does not happen with regular transactional
writesets, since the originator node will always vote success and
replica nodes are assumed to have the same global locale setting.
As such different error messages indicate different errors even if
the error code is the same (e.g. ER_DUP_KEY can happen on different
rows tables).

Use only MySQL error code (without the error message) for error voting
in case of TOI event failure.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>