The issue in this case is that we take in account the estimates from quick keys instead of rec_per_key.
The estimates for quick keys are better than rec_per_key only if we have ref(const), so we need to check
that all keyparts in the ref key are of the type ref(const).

* Versioning tests support

Closes #1043

handler::write_row() should not destroy the state of the running
index_search/index_next/... or rnd_init/rnd_next/... scan

Closes #677

Improve diagnostics. Try to guess what type user tried to type.

JSON_MERGE_PATCH implemented. Added JSON_MERGE_PRESERVE as a synonim for
the JSON_MERGE.

Fixed, now server can be configured with eq_range_index_dive_limit set in cnf file

The bug was that when using mysql_list_fields, then
table_list->schema_table_name was not filled in.
Fixed by using table_list->schema_table instead, which is always
filled in.

Fix both code paths:
- Change the test source code so it doesn't cause the "Unused variable"
  warning (which -Werror converted into error and caused CMake not to set
  HAVE_THREAD_LOCAL)

- If the system doesn't seem to support HAVE_THREAD_LOCAL, refuse to
  compile (rather than producing a binary that crashes for some tests)

Originally submitted at https://github.com/facebook/mysql-5.6/pull/905

This test takes ~6 minutes, split it for better parallelism.

Use thd_get_ha_data()/thd_set_ha_data() which protect against plugin
removal until it has THD ha_data.

Do not reset THD ha_data in rocksdb_close_connection(), cleaner approach
is to let ha_close_connection() do it.

Removed transaction objects cleanup from rocksdb_done_func(). As we lock
plugin properly, there must be no transaction objects during RocksDB
shutdown.

The bug was introduced in MariaDB 10.4.0 by
commit 0e5a4ac2
but it is good to have a regression test for this scenario
in all applicable MariaDB versions.

Cover the purge of an undo log record that was written before
the completion of ADD SPATIAL INDEX.

we had the statistics tables in the FROM list of the select.
The statistics for tables are not read in such cases, so we need
to check this case separately.

Statistics were not read for a table when we had a CREATE TABLE query.
Enforce reading statistics for commands CREATE TABLE, SET and DO.

log_buffer_extend(): Do not write to disk. Just allocate new bigger
buffer and copy contents of old one to it. Do not acquire write_mutex.

log_t::is_extending: Removed as unneeded now.

LOG_BUFFER_SIZE: Removed to make the dependence on srv_log_buffer_size
visible.

Fixing problems revealed by buildbot:

- Fixing compilation failure on Windows
- Recoding correct engines/iuds/r/insert_decimal.result

Pass a correct string pointer to RETURN_IF_INNODB_NOT_STARTED.
This was caught on Windows. The error was introduced in the
merge commit 874f8f30.

Add the test case.

The parent commit, which cherry-picked the MDEV-17167 fix from 10.3
(commit bad2f156)
fixed the bug.

             truncating a temporary table

TRUNCATE expects only one TABLE instance (which is used by TRUNCATE
itself) to be open. However this requirement wasn't enforced after
"MDEV-5535: Cannot reopen temporary table".

Fixed by closing unused table instances before performing TRUNCATE.

Problem:
========
We have a Master/Master Setup on two servers, but are only writing to one of
those servers (so it is essentially Master/Slave) We upgraded from 10.1.* to
10.2.22 last week and starting with the upgrade, we are getting duplicate key
errors on the slave. BINLOG=mixed.

Analysis:
=========
This issue happens with LOCK TABLES and binlog_format=MIXED combination. When an
UNSAFE statement is encountered in 'MIXED' mode, it is logged in the form of
'ROW' format. For all the tables that are part of LOCK TABLES list their table maps
are written into the binary log. For each table in the list a check is
done to see if 'check_table_binlog_row_based_done' flag is set or not. If it is not set
a check process is initiated to see if table qualifies for row based binary
logging or not and 'check_table_binlog_row_based_done' is set. This flag will be
cleared at the time of closing thread tables.

But there can be special cases where the LOCK TABLES contains more number of
tables but the unsafe query is actually using subset of tables from LOCK TABLES
list.

For example: LOCK TABLES locks t1,t2,t3 but the unsafe statement makes use of
only two tables t1,t3. In this case the 'check_table_binlog_row_based_done' flag
is enabled for table 't2' while writing table map, but 'close_thread_tables'
function call will not reset this flag. Since the flag is not cleared for table
't2' even a safe statement which used t2 will be logged in the form of row based
format.

This leads to an assert on debug builds and causes duplicate entries in release
builds. In release builds a statement is logged in the form of both ROW and
STATEMENT format. This causes the slave to fail with duplicate key error.

Fix:
===
During 'close_thread_tables' when LOCK TABLE modes are active "ha_reset" is done
for all the tables which were part of current statement. As mentioned in the
example 'ha_reset' is called for tables 't1' and 't3'. This will clear the
'check_table_binlog_row_based_done' flag. At this point add a check for the rest
of the tables to see if 'check_table_binlog_row_based_done' is enabled or not.
If enabled clear the flag.

Problem:
=======
Whel rpl.rpl_row_mysqlbinlog test is executed as shown below it fails with
result content mismatch.

perl mtr rpl_row_mysqlbinlog --mysqld=--binlog-annotate-row-events=1

Analysis:
=========
When row annotations are enabled the actual query is written into the binlog
which helps users to understand the query, even when row based replication is
enabled.

For example: Simple insert in row based replication looks like shown below.

#190402 16:31:27 server id 1  end_log_pos 526 	Annotate_rows:
#Q> insert into t values (10)
#190402 16:31:27 server id 1  end_log_pos 566 	Table_map: `test`.`t` mapped to number 19
# at 566
#190402 16:31:27 server id 1  end_log_pos 600 	Write_rows: table id 19 flags: STMT_END_F

BINLOG '
B0GjXBMBAAAAKAAAADYCAAAAABMAAAAAAAEABHRlc3QAAXQAAQMAAQ==
B0GjXBcBAAAAIgAAAFgCAAAAABMAAAAAAAEAAf/+CgAAAA==
'/*!*/;
# at 600

The test creates some binary log events and redirects them into a SQL file.
Executes RESET MASTER and sources the SQL file back on clean master and verifies
that the data is available. Please refer following steps.

../client/mysqlbinlog ./var/mysqld.1/data/master-bin.000001 > test.sql
../client/mysql -uroot -S./var/tmp/mysqld.1.sock -Dtest  < test.sql
../client/mysqlbinlog ./var/mysqld.1/data/master-bin.000001 -v > row.sql

When the row based replication specific SQL file is sourced once again on master
the newly generated binlog will treat the entire "BASE 64" encoded event as
query and write it into the binary log.

Output from 'row.sql':

#Q> BINLOG '
#Q> B0GjXBMBAAAAKAAAADYCAAAAABMAAAAAAAEABHRlc3QAAXQAAQMAAQ==
#Q> B0GjXBcBAAAAIgAAAFgCAAAAABMAAAAAAAEAAf/+CgAAAA==
#190402 16:31:27 server id 1  end_log_pos 657 	Table_map: `test`.`t` mapped to number 23
# at 657
#190402 16:31:27 server id 1  end_log_pos 691 	Write_rows: table id 23 flags: STMT_END_F

BINLOG '
B0GjXBMBAAAAKAAAAJECAAAAABcAAAAAAAEABHRlc3QAAXQAAQMAAQ==
B0GjXBcBAAAAIgAAALMCAAAAABcAAAAAAAEAAQH+CgAAAA==
### INSERT INTO `test`.`t`
### SET
###   @1=10
'/*!*/;
# at 691


This is expected behaviour as we cannot extract query from BASE 64 encoded
input. This causes more number of binary logs to be generated when the test is
executed with row annotations.

The following lines from test assumes that only two binary logs will contain
entire data.

 --echo --- Test 4 Second Remote test --
---exec $MYSQL_BINLOG --read-from-remote-server --user=root --host=127.0.0.1
	--port=$MASTER_MYPORT master-bin.000001 > $MYSQLTEST_VARDIR/tmp/remote.sql
---exec $MYSQL_BINLOG --read-from-remote-server --user=root --host=127.0.0.1
	--port=$MASTER_MYPORT master-bin.000002 >> $MYSQLTEST_VARDIR/tmp/remote.sql

In a case when row annotations are enabled the data gets spread across four
binary logs. As test uses only the first two binary log files, data available in
other binary logs gets missed. Hence test fails with result content mismatch as
less data is avaialble.

Fix:
====
Use "-to-the-last" option of "mysqlbinlog" tool which will ensure that all the
available binary log specific contents are included in .sql file.