In the function prev_record_reads where one finds the different row combinations for a
subset of partial join, it did not take into account the selectivity of tables
involved in the subset of partial join.

Unfortunate DROP TEMPORARY..IF EXISTS on a regular table may allow
subsequent CREATE TABLE statements to steal away the PFS_table_share
instance from the dropped table.

In commit d1e6b0bc
some code was supposed to be modified, but instead
it got duplicated. Remove the duplicated copy.

* use compile_time_assert instead of DBUG_ASSERT

* don't use thd->clear_error(), because
  * the error was already consumed by the error handler, so there is
     nothing to clear
  * it's dangerous to clear errors indiscriminately, if the error came
    from outside of read_statistics_for_tables() it must not be cleared

mysql_insert() first opens all affected tables (which implicitly
starts a transaction in InnoDB), then stat tables.
A failure to open a stat table caused open_tables() to abort
the current stmt transaction (trans_rollback_stmt()). So, from the
server point of view the following ha_write_row()-s happened outside
of a transactions, and the server didn't bother to commit them.

The server has a mechanism to prevent a transaction being
unexpectedly committed or rolled back in the middle of a statement -
if an operation takes place _in a sub-statement_ it cannot change
the transaction state. Operations on stat tables are exactly that -
they are not allowed to change a transaction state. Put them in
a sub-statement to make sure they don't.

following Fedora recommendations (see %systemd_post macro in FC29)
let's do `systemctl preset` on the first installation of the server

This reverts commit 396313d3.

Apply the changes to InnoDB and XtraDB that had been
inadvertently skipped in the merge
commit ae476868

That merge failure sabotaged part of MDEV-20127:
>Revert a problematic auto_increment_increment 'fix' from 2014.
>This involves replacing the MDEV-8827 fix and in 10.1,
>removing some WSREP instrumentation.

The code changes were re-merged manually by executing the following:

 # Get the parent of the problematic merge.
git checkout ae476868^
 # Perform the merge again.
git merge ae476868^2
 # Get the conflict resolution from that merge.
git checkout ae476868 .
 # Note: Any changes to these files were removed (empty diff)!
git diff HEAD storage/{innobase,xtradb}/handler/ha_innodb.cc
 # Apply the code changes:
git diff cf403934^2..MERGE_HEAD \
storage/{innobase,xtradb}/handler/ha_innodb.cc|
patch -p1

Basicaly it's an uninitialized read. 165 is 0xa5 which comes from TRASH_ALLOC()

Fix by calling a class ctor which initializes problematic
TMP_TABLE_PARAM::force_copy_fields field

In debug build, whenever MEMORY table instance gets closed it performs
consistency check without protection. It may cause server crash if
executed concurrently with DML.

Moved consistency check to ha_heap::external_lock(F_UNLCK), so that it
is protected by THR_LOCK.

Ever since MariaDB 10.0 (and MySQL 5.6.8), the innodb_log_file_size
and innodb_log_files_in_group can be changed between server restarts,
and the redo log files will be resized on server startup if needed.

- fts_optimize_thread() uses dict_table_t object instead of table id.
So that it doesn't acquire dict_sys->mutex. It leads to remove the
hang of dict_sys->mutex between fts_optimize_thread() and other threads.

- in_queue to indicate whether the table is in fts_optimize_queue. It
is protected by fts_optimize_wq->mutex to avoid any race condition.

- fts_optimize_init() adds the fts table to the fts_optimize_wq

InnoDB stores synced_doc_id + 1 value in FTS_CONFIG table. But
while reading the synced doc id from FTS_CONFIG table after restart,
InnoDB should read synced_doc_id - 1 to get the actual synced
doc id value.

using a specially crafted strings one could overflow `shift`
variable and cause a crash by dereferencing d10[-2147483648]
(on a sufficiently old gcc).

This is a correct fix and a test case for

Bug #29723340: MYSQL SERVER CRASH AFTER SQL QUERY WITH DATA ?AST

update mysqlaccess version

IS NULL or <=> with unique field does not mean unique row,
because several NULL possible,
so we can not convert to normal join in this case.

Data should be sent with length.

Old InnoDB/XtraDB versions only initialized FIL_PAGE_TYPE for
B-tree pages (to FIL_PAGE_INDEX), and left it uninitialized
(possibly containing FIL_PAGE_INDEX) for others. In MySQL
or MariaDB 5.5, the field is initialized on almost all pages,
but still not all of them.

In MariaDB 10.2 and later, buf_flush_init_for_writing() would
initialize the FIL_PAGE_TYPE on such old pages, but only after
passing the debug assertion that we are now removing from 10.1.
There, we will be able to modify fil_crypt_rotate_page() so
that it will skip the key rotation for pages that contain 0
in FIL_PAGE_TYPE.

In MariaDB 10.1, there is no logic that would initialize
FIL_PAGE_TYPE on data pages in old data files after an update.
So, encryption key rotation may routinely cause page flushes
on pages that contain 0 in FIL_PAGE_TYPE.

This is a backport of commit ec28f953
to MariaDB Server 10.1.

When the mysqld_multi script passes the --defaults-group-suffix
option to mysqld, it must remove the initial substring with the
group name ("mysqld") from option value, because otherwise substring
"mysqld" will be added to the group name and then the group name
will contain the word "mysqld" twice, which is wrong, because
mysqld itself adds the suffix received to the group name.

buf_flush_init_for_writing(): Assert that FIL_PAGE_TYPE is set
except when creating a new data file with a dummy first page.

buf_dblwr_create(): Ensure that FIL_PAGE_TYPE on all pages
will be initialized. Reset buf_dblwr_being_created at the end.

In the function recv_parse_or_apply_log_rec_body() there are debug checks
for validating the state of the page when redo log records are being
applied. Most notably, FIL_PAGE_TYPE should be set before anything else
is being written to the page.

ibuf_add_free_page(): Set FIL_PAGE_TYPE before performing any other changes.

Apply the correct pattern for debug instrumentation:

SET @save_dbug=@@debug_dbug;
SET debug_dbug='+d,...';
...
SET debug_dbug=@save_dbug;

Numerous tests use statements of the form

SET debug_dbug='-d,...';

which will inadvertently enable all DBUG tracing output,
causing unnecessary waste of resources.