A deadlock can occur when the wsrep applier thread while
executing FLUSH TABLES waits for MDL lock owned by other
local transactions, which in turn are waiting for commit
order if their seqno comes after one assigned to FLUSH
TABLES.
Fixed by making sure that the wsrep applier thread while
executing FLUSH TABLES does not wait for table share(s)
to be removed from table definition cache.

In wsrep BF we have already took lock_sys and trx
mutex either on wsrep_abort_transaction() or
before wsrep_kill_victim(). In replication we
could own lock_sys mutex taken in
lock_deadlock_check_and_resolve().

As a fix for MDEV-8208, for initial wsrep threads, the
invocation of init_for_queries() was moved after plugins
were initialized. Due to which, OPTION_BEGIN bit of wsrep
applier THD (originally set in wsrep_replication_process)
got reset due to implicit commit within init_for_queries().
As a result, events from a multi-statement transaction from
another node were committed separately by the applier thread,
which leads to an assertion as they all carry same seqno.

Fixed by making sure that variable.option_bits are restored
post init_for_queries(). Also restored server_status.
Added a test case.

            of the plugins

Removed exit() from daemon_example, pass error to caller instead.
Also removed unused my_abort_hook.

Check now allows zero length decimals too.

(backporting Adam Chainz patch to 10.0)

they used to be unstable, fixed in 7.1.8
and apparently broken again now

* mostly update result files
* also updating test/include files to match 5.6

* use --sort_result in test files as needed
* remove old and wrong mariadb-5.3 related partitioning hack
   from ha_tokudb.cc

Fixed moving charset from definition to the value.

Update modified-counter also if update effects non-indexed columns.

Backport pull request #125 from grooverdan/MDEV-8923_innodb_buffer_pool_dump_pct to 10.0

WL#6504 InnoDB buffer pool dump/load enchantments

This patch consists of two parts:

    1. Dump only the hottest N% of the buffer pool(s)
    2. Prevent hogging the server duing BP load

From MySQL - commit b409342c43ce2edb68807100a77001367c7e6b8e

Add testcases for innodb_buffer_pool_dump_pct_basic.

Part of the code authored by Daniel Black

MDEV-9276: MySQL Bug #78754: FK definitions missing from SHOW CREATE TABLE in "innodb_read_only" mode

As galera node (slave) received query log events from an async
replication master, it partially wrote the updates made to replication
state table (mysql.gtid_slave_pos) to galera transaction writeset post
TOI. As a result, the transaction handle, thus created within galera,
was never freed/purged as the corresponding trx did not commit.
Thus, it kept piling up for every query log event and was only reclaimed
upon server shutdown when the transaction map object got destructed.
Fixed by making sure that updates in replication slave state table
are not written to galera transaction writeset and thus, not replicated
to other nodes.

Fix logic around retrying failed Windows async IO as synchronous IO . os_file_write/read macros were wrong (had wrong number of args), among other things

In wsrep brute force (BF) we have already took lock_sys and trx
mutex either on wsrep_abort_transaction() or
before wsrep_kill_victim().

  modified:   storage/connect/tabjson.cpp

MDEV-7655 SHOW CREATE TABLE returns invalid DDL when using virtual columns along with a table collation

that was mistakenly merged from mysql-5.5.47

(introduces valgrind failures in main.sp, because Field_varstring
columns are created as FIELD_NORMAL and that causes aria to
read bytes between the actual value length and field max length)

that was mistakenly merged from mysql-5.5.47