This assertion would fail when a secondary index record for an
instantly added column was accessed.

It is unclear to me why this code path is executed so rarely.
I was unable to cover it even when using FORCE INDEX.

row_sel_sec_rec_is_for_clust_rec(): Remove the assertion, and use
the proper function rec_get_nth_cfield().

row_sel_store_mysql_field_func(): Simply use rec_get_nth_cfield()
instead of duplicating its logic.

Problem:
========
MLOG_FILE_WRITE_CRYPT_DATA redo log fails to apply type for
the crypt_data present in the space. While processing the double-write
buffer pages, page fails to decrypt. It leads to warning message.

Fix:
====
Set the type while parsing MLOG_FILE_WRITE_CRYPT_DATA redo log.
If type and length is of invalid type then mark it as corrupted.

Corrects 94d722b6

- There is no need to wait for crypt thread to stop accessing space while
dropping the garbage encrypted tablespace during recover.

Allow table definition cache be bigger than open table cache (due to problem with VIEWs and prepared statements).

Implement according to standard SQL specification 2008.
The check_constraints table is used for fetching metadata about
the constraints defined for tables in all databases.

There were some result files which failed after running mtr.
These files are updated with newly create record with mtr --record.

This might apply to 10.1 and 10.2 as well, but I cannot run that test
there without installing third-party software. The test would expect
"innobackupex" to be in path. If I add a wrapper script that invokes
mariabackup --innobackupex, then on 10.2 the cluster would fail to start
up due to a version number mismatch.

Poisoning memory after munmap() and friends is totally incorrect as this memory
could be anything.

os_mem_free_large(): remove memory poisoning

If galera.galera_gtid_slave_sst_rsync is repeated more than once it will fail due incorrect GTID position. After stopping SLAVE node reset also GTID_SLAVE_POS variable.

The merge commit d833bb65 did not
correctly merge the commit 03eb1593.

Closes #948

This mutex can be freed when server shuts down (when thread_count goes down to 0)
, but it is still used inside THD::~THD() when Statement_map is destroyed.

The fix is to call Statement_map::reset() at the point where thread_count
is still positive, and avoid locking LOCK_prepared_stmt_count in THD
destructor.

Add the test case. The actual bug was fixed in MDEV-17541.

Closes #811

When performing a hash search via HASH_SEARCH we first look at a key of a node
and then at its pointer to the next node in chain. If we have those in one cache
line instead of a two we reduce memory reads.

I found dict_table_t, fil_space_t and buf_page_t suitable for such improvement.

This was introduced in 1a7a0189
MDEV-16557 Remove INNOBASE_SHARE::idx_trans_tbl

ha_innobase::innobase_get_index: remove incorrect assertion.
Index nullability is checked in subsequent ifs.

Closes #1079

The fil_system_t::name_hash was removed already earlier,
in commit 05863142.
The fil_space_t::name_hash was thus made an orphan data field.

MDEV-16499 ER_NO_SUCH_TABLE_IN_ENGINE followed by "Please drop the table and recreate" upon adding FULLTEXT key to table with virtual column

log_group_file_header_flush(): Use a stack-local variable
instead of the heap-allocated buffers.

Closes #1060

Closes #965

Closes #983, #984

MDEV-18224 MTR's internal check of the test case 'innodb.recovery_shutdown' failed due to extra #sql-ib*.ibd files

The test innodb.recovery_shutdown would occasionally fail,
because recovered incomplete transactions would be conflicting
with DROP TABLE, causing the background drop table queue to be invoked.

Add a slow shutdown before dropping the tables, so that the
recovered transactions will be rolled back. Starting with MDEV-14705,
normal shutdown would abort the rollback of recovered transactions.

Change mysql_alter_user to log alter user command.

Fix one more bug in "DDL redo" phase in prepare
If table was renamed, and then new table was created with the old name,
prepare can be confused, and .ibd can end up with wrong name.

Fix the order of how DDL fixup is applied , once again - ".new" files
should be processed after renames.

If, during backup
1) Innodb table is dropped (after being copied to backup) and then
2) Before backup finished, another Innodb table is renamed, and new name
is the name of the dropped table in 1)

then, --prepare fails with assertion, as DDL fixup code in prepare
did not handle this specific case.

The fix is to process drops before renames, in prepare DDL-"redo" phase.

MDEV-15022 - travis: add versioning to test suite