for the small InnoDB table

This bug was introduced by the patch 6c414fcf.
The patch has not taken into account that some objects of the Field_* types
are created only for TABLE_SHARE and the field 'table' is set to NULL
for them. In particular such are objects created to store statistical
min/max values for columns.

If the command CREATE OR REPLACE TABLE really replaces a table then
it should remove all data on this table from all statistical tables.

           for blob column

ANALYZE TABLE <table> does not collect statistical data on min/max values
for BLOB columns of <table>. However these values can be added into
mysql.column_stats manually by executing proper statements.
Unfortunately this led to a memory leak because the memory allocated
for these values was never freed.
This patch provides the server with a function to free memory allocated
for min/max statistical values of BLOB types.

Temporarily changed the test case until MDEV-16711 is fixed as without
this fix the test case for MDEV-16757 did not fail only for 10.0.

"my_snprintf(NULL, 0, ...)" does not follow what snprintf does. Change
the call in wsrep_dump_rbr_buf_with_header to use snprintf (note that
wsrep_dump_rbr_buf was using snprintf all the way).

Fix an off-by-one error in comparison so it actually prints the output

in the "Adopt Debian's fix-FTBFS-on-GNU-Hurd.patch",
DBUG_VOID_RETURN has been used instead of "return"

Change the float comparison function to use a negated version when
comparing for equality. This actually produces less code when compiling
with optimizations (O3) on.

- Took the original patch by Ondrej Sury;
- Applied a fix for a known problem in the patch:
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882062
- Fixed a few other issues

table->in_use is not always set and a KILL signal can arrive anytime.

MDEV-7257 made a dump thread to read from binlog concurrently with
writers as long as the read bytes are below a water-mark
(MYSQL_BIN_LOG::binlog_end_pos). However it appeared to be possible a
dump thread reader reach out for bytes past the water mark through a
feature of IO_CACHE that fills in the internal buffer and while doing
so it could read what the reader is not supposed to see (the bytes
above MYSQL_BIN_LOG::binlog_end_pos).

The issue is fixed with constraining the IO_CACHE buffer fill to respect
the watermark.

An added unit test proves reading from file is bound to an external
parameter
passed to {IO_CACHE::end_of_file} cache member.

rnd_pos_by_record calls ha_rnd_pos, which does the counting

Only close stdin if it was open initinally. Otherwise we may close file
descriptor which is reused for different puprose (specifically for binlog
index file in case of this bug).

This is a typical systemd response where it tries to shutdown the
joiner (due to "timeout") before the joiner manages to complete SST.

wsrep_sst_wait
wsrep_SE_init_wait
	While waiting the operation to finish use mysql_cond_timedwait
	instead of mysql_cond_wait and if operation is not finished
	extend systemd timeout (if needed).

dict0dict.cc

buf_LRU_drop_page_hash_for_tablespace(): Return whether any adaptive
hash index entries existed. If yes, the caller should keep retrying to
drop the adaptive hash index.

row_import_for_mysql(), row_truncate_table_for_mysql(),
row_drop_table_for_mysql(): Ensure that the adaptive hash index was
entirely dropped for the table.

MDEV-15953 Alter InnoDB Partitioned Table Moves Files (which were originally not in the datadir) to the datadir

ha_innobase::prepare_inplace_alter_table: preserve DATA DICTIONARY for table

Observed and described
partitioned engine execution time difference
between master and slave was caused by excessive invocation
of base_engine::rnd_init which was done also for partitions
uninvolved into Rows-event operation.
The bug's slave slowdown therefore scales with the number of partitions.

Fixed with applying an upstream patch.

References:
----------
https://bugs.mysql.com/bug.php?id=73648
Bug#25687813 REPLICATION REGRESSION WITH RBR AND PARTITIONED TABLES

           optimizer_use_condition_selectivity = 4

It does not makes sense to try to read statistics for temporary tables
because it's not collected.

This reverts commit d39629f0.

Because running mtr for many hours with no output whatsoever
is not really what we should do.

And in 5.5 `make test` just works anyway, nothing to fix here.

MDEV-16534 PPC64: Unexpected error with a negative value into auto-increment columns in HEAP, MyISAM, ARIA

Revert 7bbe324f
Fix the bug differently (in log_event.cc)
Fix the test case to actually fail without the bug fix

In this case we are accessing incorrect memory when we have mergeable semi-joins.
In the case when we have mergeable semi joins parent select will have a table count
of all the tables in that select plus all the tables involved in the IN-subquery.
But this table count does not include the "sjm table" (only includes the inner and outer tables)
denotes as <subquery#> in explain.

* xtrabackup no longer support --compact
* wsrep_sst_mysqldump wasn't always using --default-file
* wsrep_sst.cc overquoted --default-file for wsrep_sst_mysqldump

also remove redundant lines config and test lines, compiler warnings,
and mark big tests as big.

backport cb21e117 from 10.2

Merge following change from 10.2

revision-id: d52cff9f10aeea208a1058f7b5527e602125584c (mariadb-10.2.14-25-gd52cff9)
parent(s): bc250145
author: Sachin Setiya
committer: Sachin Setiya
timestamp: 2018-04-04 12:26:06 +0530
message:

MDEV-15611 Due to the failure of foreign key detection, Galera...
slave node killed himself.

Problem:- If we try to delete table with foreign key and table whom it is
referring with wsrep_slave_threads>1 then galera tries to execute both
Delete_rows_log-event in parallel, which should not happen.

Solution:- This is happening because we do not have foreign key info in
write set. Upto version 10.2.7 it used to work fine. Actually it happening
because of issue in commit 2f342c45. wsrep_must_process_fk should be used
with negation.