Context involves semicolon batching, and the error starts 10.2
No reproducible examples were made yet, but TCP trace suggests
multiple packets that are "squeezed" together (e.g overlong OK packet
that has a trailer which is belongs to another packet)

Remove thd->get_stmt_da()->set_skip_flush() when processing a batch.
skip_flush stems from the COM_MULTI code, which was checked in during
10.2 (and is never used)

The fix is confirmed to work, when evaluated by bug reporter (one of them)

We never reproduced it locally, with multiple tries
thus the root cause analysis is still missing.

Problem seems to be the fact that we did not enforce correct
applier thread numbers after every command that effects them.
Test changes only.

* Remove those tests that will not be supported on that release.
* Make sure that correct tests are disabled and have MDEVs
* Sort test names

This should not be merged upwards.

Problem seems to be the fact that we did not enforce correct
applier thread numbers after every command that effects them.
Test changes only.

* Remove those tests that will not be supported on that release.
* Make sure that correct tests are disabled and have MDEVs
* Sort test names

This should not be merged upwards.

The symbol SRV_MASTER_PURGE_INTERVAL became unused in
mysql/mysql-server@42f36919584e82c621dbec1e69fd05ab023c54c6
when separate purge threads were introduced in MySQL 5.6.5.

Do not materialize a semi-join nest if it contains a materialized derived
table /view that potentially can be subject to the split optimization.
Splitting of materialization of such nest would help, but currently there
is no code to support this technique.

- n_ext value may be less than dtuple_get_n_ext(dtuple) when PK is being
updated and new record inherits the externally stored fields from
delete mark old record.

- Added the test case in innodb_fts suite
- Updated copyright year in row0mysql.cc

Problem:
=======
After discarding the table, fts_optimize_thread aborts during shutdown.
InnoDB fails to remove the table from fts_optimize_wq and it leads to
the fts_optimize_thread to lookup for the auxiliary table and fails.

Fix:
====
While discarding the fts table, remove the table from fts_optimize_wq.

buf_flush_or_remove_pages(): Only define BUF_LRU_DROP_SEARCH_SIZE
and dependent code when the adaptive hash index has been enabled.

JIRA:https://jira.mariadb.org/browse/MDEV-17292

Closes #1443

Quotes added to output.

For automatic number of opened files limit take into account number of table instances for table cache

MDEV-21616: Server crash when using "SET STATEMENT max_statement_time=0 FOR desc xxx" lead to collapse

Main select should be pushed first.

row_log_table_get_pk_old_col(): For replacing a NULL value for a
column of the being-added primary key, look up the correct
default value, even if columns had been instantly reordered or
dropped earlier. This ought to have been broken ever since
commit 0e5a4ac2 (MDEV-15562).

ha_innobase::commit_inplace_alter_table(): After
ALTER_STORED_COLUMN_ORDER, ensure that the virtual column metadata
will be reloaded also when the table is not being rebuilt.

We need to release global system variables mutex before
doing wsrep_init to avoid race with next show status and
we need to save wsrep_on value as it is changed on wsrep_init.
Added test case.

When wsrep_on is changed to ON we might need to run wsrep_init
if wsrep-provider is set and wsrep is not inited.

Use of freed memory is better caught by AddressSanitizer,
especially with ASAN_POISON_MEMORY_REGION that is aliased
by MEM_NOACCESS and UNIV_MEM_FREE.

The column INFORMATION_SCHEMA.INNODB_MUTEXES.NAME is not populated ever since
commit 2e814d47 applied the InnoDB changes from
MySQL 5.7.9 to MariaDB Server 10.2.2.

Since the same commit, the view is only providing information about
rw_lock_t, not any mutexes.

For now, let us convert the source code file name and line number of
the rw_lock_t creation into a name. A better option in the future might
be to store the information somewhere where it can be looked up by
mysql_pfs_key_t, and possibly to remove the CREATE_FILE and CREATE_LINE
columns.

MDEV-20001 Potential dangerous regression: INSERT INTO >=100 rows fail for myisam table with HASH indexes

Problem:-

So the issue is when we do bulk insert with rows
> MI_MIN_ROWS_TO_DISABLE_INDEXES(100) , We try to disable the indexes to
speedup insert. But current logic also disables the long unique indexes.

Solution:- In ha_myisam::start_bulk_insert if we find long hash index
(HA_KEY_ALG_LONG_HASH) we will not disable the index.

This commit also refactors the mi_disable_indexes_for_rebuild function,
Since this is function is called at only one place, it is inlined into
start_bulk_insert

mi_clear_key_active is added into myisamdef.h because now it is also used
in ha_myisam.cc file.

(Same is done for Aria Storage engine)

Use FLOOR rounding for DECIMAL_RESULT item_expr in partition function.

See also original report:
http://bugs.debian.org/946671

Using mysqlhotcopy, the following error occurs:

DBD::mysql::db do failed: You can't use locks with log tables at
/usr/bin/mysqlhotcopy line 545.

Author:

Paul Szabo psz@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia

Race condition when innodb_lock_wait_timeout (default 50 seconds)
exceeds for 'send update', but information_schema.innodb_lock_waits
still sees this wait or it my exit by timeout. My occur on overloaded
host.

If we have long unique key for aria engine return too long key error, because
Aria does not support key on virtual generated column.

Starting with MariaDB Server 10.4, C++11 is being used.
Hence, std::atomic should be preferred to my_atomic.

Fix up commit f5c080c7