The problem occurs in 10.2 and earlier releases of MariaDB Server because the
Partition Engine was not pushing the engine conditions to the underlying
storage engine of each partition.  This caused Spider to return the first 5
rows in the table with the data provided by the customer.  2 of the 5 rows
did not qualify the WHERE clause, so they were removed from the result set by
the server.

To fix the problem, I have back-ported support for engine condition pushdown
in the Partition Engine from MariaDB Server 10.3.

Author:
  Jacob Mathew.

Reviewer:
  Kentoku Shiba.

This assertion fails in thread that removes all table instances for
particular table from table cache (e.g. "DROP TABLE") while another
thread evicts table instance of the same table from table cache
concurrently.

After "MDEV-10296 - Multi-instance table cache" there is a gap in
eviction code of tc_add_table() between removing table from free_tables
and all_tables not protected by any mutexes.

This is now valid table cache state, however assertion wasn't amended
along with original patch. Moved assertion down, after waiting for such
table instances to get closed.

This problem manifested itself when a join query used two or more
materialized CTE such that each of them employed the same recursive CTE.
The bug caused a crash. The crash happened because the cleanup()
function was performed premature for recursive CTE. This clean up was
induced by the cleanup of the first CTE referenced the recusrsive CTE.
This cleanup destroyed the structures that would allow to read from the
temporary table containing the rows of the recursive CTE and an attempt to read
these rows for the second CTE referencing the recursive CTE triggered a
crash.
The clean up for a recursive CTE R should be performed after the cleanup
of the last materialized CTE that uses R.

recv_addr_state, recv_addr_t: Define in log0recv.cc only.

Because innodb_file_per_table can be enabled at runtime after it
was disabled at startup, it is better to always register the same
innobase_hton->tablefile_extensions. Besides,
innodb_file_per_table=OFF does not prevent loading tables that may
have been created earlier with the .ibd file extension.

Remove plugin-load option from mariabackup. It does not needed to be an
option (we only need to store the plugin-load value during backup phase,
and reuse the same value during --prepare).

Fix is to read plugin-load from backup-my.cnf during prepare.

Fix exit condition for the log copying thread.

(https://github.com/facebook/rocksdb/issues/4344)
Also, disable /permissive- flag if set, it breaks rocksdb compilation
in 10.3 on older versions of Windows 8.1 SDK.

It uses --slave-use-idempotent-for-recovery which is not available in MariaDB.

Remove the mismatch betwen list of man pages in CMakeLists.txt and
actual files.

Direct IO doesnt work on all filesystems, e.g. it doesnt work on the
disk of kvm-bintar-trusty-amd64.

This regression was introduced in MDEV-16515.
We would fail to drop a temporary table on client disconnect,
because trx_is_interrupted() would hold. To add insult to
injury, in MariaDB 10.1, InnoDB temporary tables are actually
persistent, so the garbage temporary tables will never be dropped.

row_drop_table_for_mysql(): If several iterations of
buf_LRU_drop_page_hash_for_tablespace() are needed,
do not interrupt dropping a temporary table even after
the transaction was marked as killed.

Server shutdown will still terminate the loop, and also DROP TABLE
of persistent tables will keep checking if the execution was aborted.

This reverts commit 75dfd4ac.

It uses a feature that's not available in MariaDB

It uses a feature that's not available in MariaDB

Plugin version name fixed.

Let '\\' and '/' symbols to be part of a group name.

           Field_iterator_table_ref::set_field_iterator

Several functions that processed different prepare statements missed
the DT_INIT flag in last parameter of the open_normal_and_derived_tables()
calls. It made context analysis of derived tables dependent on the order in
which the derived tables were processed by mysql_handle_derived(). This
order was induced by the order of SELECTs in all_select_list.
In 10.4 the order of SELECTs in all_select_list became different and lack
of the DT_INIT flags in some open_normal_and_derived_tables() call became
critical as some derived tables were not identified as such.

Merged https://github.com/MariaDB/server/pull/617 authored by
Colin Mollenhour.