As noted in commit 0b66d3f7,
MariaDB does not support CREATE TABLESPACE for InnoDB.
Hence, some code that was added in
commit fec844ac
and originally in
mysql/mysql-server@c71dd213bd434c0579e454ab8880e6d3756b0fb0
is unused in MariaDB and should be removed.

trx_undo_left(): Return 0 in case of an overflow, instead of
returning a negative number interpreted as a large positive number.
Also, add debug assertions to check that the pointer is within
the page area. This should allow us to catch bugs like
MDEV-24096 easier in the future.

The function ibuf_merge_or_delete_for_page() was always being
invoked with update_ibuf_bitmap=true ever since
commit cd623508
fixed up something after MDEV-9566.

Furthermore, the parameter page_size is never being passed as a
null pointer, and therefore it should better be a reference to
a constant object.

- Patch is solving generating report on warning
        To repeat the error run single worker:
        ```
        ./mtr --mysqld=--lock-wait-timeout=-xx 1st 1st --force --parallel 1
        ```
        or `N` workers with `N+1` tests with failures and `force`
        ```
        ./mtr --mysqld=--lock-wait-timeout=-xx 1st 1st grant5 --force --parallel 2
        ```
- Patch is doing cosmetic fix of `current_test` log file which holds the old log value of test `CURRENT TEST:..` in `mark_log()` in case of `unknown option` and as such
  the logic which is using it's content doesn't output valid log content and doesn't generate valid `$test->{'comment'}` message.asdf

- Closing the socket/handler after the removing the handler from IO for
consistency

Reviewed by: serg@mariadb.com

The row_log_t::mutex is a mutex, yet it was instrumented as
rw-lock in PERFORMANCE_SCHEMA.

The instrumentation that was added in
commit 90635c6f (MDEV-7620)
was effectively reverted in MariaDB Server 10.2.2, in
commit 2e814d47
(which stopped reporting the statistics) and
commit fec844ac
(which stopped updating the statistics).

Let us remove the orphan data members to reduce the memory footprint.

Changed the test so that it does not rely on specific auto increment
ids. With Galera's default wsrep_auto_increment_control setting it is
not guaranteed that auto increments always start from 1. The test was
occasionally failing due to result content mismatch.
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

C++11 is allowed only starting with MariaDB Server 10.4.

This follows up commit
commit 94a520dd and
commit 7c5519c1.

After these changes, the default test suites on a
cmake -DWITH_UBSAN=ON build no longer fail due to passing
null pointers as parameters that are declared to never be null,
but plenty of other runtime errors remain.

This was missed in commit d6ea03fa.

Add --system={all, users, plugins, udfs, servers, stats, timezones}

This will dump system information from the server in
a logical form like:
* CREATE USER
* GRANT
* SET DEFAULT ROLE
* CREATE ROLE
* CREATE SERVER
* INSTALL PLUGIN
* CREATE FUNCTION

"stats" is the innodb statistics tables or EITS and
these are dumped as INSERT/REPLACE INTO statements
without recreating the table.

"timezones" is the collection of timezone tables
which are important to transfer to generate identical
results on restoration.

Two other options have an effect on the SQL generated by
--system=all. These are mutually exclusive of each other.
* --replace
* --insert-ignore

--replace will include "OR REPLACE" into the logical form
like:
* CREATE OR REPLACE USER ...
* DROP ROLE IF EXISTS (MySQL-8.0+)
* CREATE OR REPLACE ROLE ...
* UNINSTALL PLUGIN IF EXISTS (10.4+) ... (before INSTALL PLUGIN)
* DROP FUNCTION IF EXISTS (MySQL-5.7+)
* CREATE OR REPLACE [AGGREGATE] FUNCTION
* CREATE OR REPLACE SERVER

--insert-ignore uses the construct " IF NOT EXISTS" where
supported in the logical syntax.

'CREATE OR REPLACE USER' includes protection against
being run as the same user that is importing the mysqldump.

Includes experimental support for dumping mysql-5.7/8.0
system tables and exporting logical SQL compatible with MySQL.

Updates mysqldump man page, including this information and
(removing obsolute bug reference)

Reviewed-by: anel@mariadb.org

This regression was introduced in
commit afc9d00c.
This is a partial backport of
commit 199863d7 from 10.4.

 MDEV-24033: SIGSEGV in __memcmp_avx2_movbe from queue_insert | SIGSEGV in __memcmp_avx2_movbe from native_compare

The issue here was the system variable max_sort_length was being applied
to decimals and it was truncating the value for decimals to the number
of bytes set by max_sort_length.
This was leading to a buffer overflow as the values were written
to the buffer without truncation and then we moved the offset to
the number of bytes(set by max_sort_length), that are needed for comparison.

The fix is to not apply max_sort_length for fixed size types like INT,
DECIMALS and only apply max_sort_length for CHAR, VARCHARS, TEXT and
BLOBS.

cmake has caught up and since version 3.18 it started supporting
CPACK_RPM_POST_TRANS_SCRIPT_FILE, something we've supported for
two years and cmake 2.8.11. Both implementation add %posttrans tag
and rpmbuild gets confused.

Disable our implementation for cmake 3.18+

Test itself is not deterministic.

Use 9 byte (min length packet)

and restore the test modified in the same commit
(the non-replication related deadlock will be reported separately)

Implement a different fix for
"MDEV-19232: Floating point precision / value comparison problem"

Instead of truncating decimal values after every division,
truncate them for comparison purposes.

This reverts commit 62d73df6 but keeps the test.

followup for 3e807d25 and eae10a87

In case of direct execution(stmtid=-1, mariadb_stmt_execute_direct in C
API) application is in control of how many parameters client sends to
the server. In case this number is not equal to actual query parameters
number, the server may start to interprete packet data incorrectly, e.g.
starting from the size of null bitmap. And that could cause it to crash
at some point. The commit introduces some additional COM_STMT_EXECUTE
packet sanity checks:
- checking that "types sent" byte is set, and the value is equal to 1.
  if it's not direct execution, then that value is 0 or 1.
- checking that parameter type value is a valid type, and parameter
  flags value is 0 or only "unsigned" bit is set
- added more checks that read does not go beyond the end of the packet

mariabackup deallocated uninitialized
write_filt_ctxt.u.wf_incremental_ctxt in xtrabackup_copy_datafile() when
some table should be skipped due to parsed DDL redo log record.

Old SDK is missing #define SECURITY_MAX_SID_STRING_CHARACTERS

Remove unnecessary condition and add necessary include
for non debug Galera library.

All relevant InnoDB changes from MySQL 5.7.32 have been applied
in preceding commits.

Tighten access control - deny FILE_CREATE_PIPE_INSTANCE permission to
everyone except current user (the one that runs mysqld)

Patch removes dict_index_t::stats_latch. Table/index statistics now
protected with dict_sys->mutex. That way statistics computation can
happen in parallel in several threads and dict_sys->mutex will be locked
only for a short period of time.

This patch is a joint work with Marko Mäkelä

dict_index_t::lock: make mutable which allows to pass const pointer
when only lock is touched in an object

btr_height_get()
btr_get_size(): make index argument const for better type safety

btr_estimate_number_of_different_key_vals(): now returns computed values
instead of setting fields in dict_index_t directly

remove everything related to dict_index_t::stats_latch

dict_stats_index_set_n_diff(): now returns computed values instead
of setting fields in dict_index_t directly

dict_stats_analyze_index():  now returns computed values instead
of setting fields in dict_index_t directly

Reviewed by: Marko Mäkelä

Let us introduce a dummy variable innodb_max_purge_lag_wait
for waiting that the InnoDB history list length is below
the user-specified limit. Specifically,

SET GLOBAL innodb_max_purge_lag_wait=0;

should wait for all history to be purged. This could be useful
when upgrading from an older version to MariaDB 10.3 or later,
to avoid hitting MDEV-15912.

Note: the history cannot be purged if there exist transactions
that may see old versions.

Reviewed by: Vladislav Vaintroub