If innodb_data_home_dir path specified in the configuration file
then rsync IST/SST will fail because the wsrep_sst_rsync.sh script
does not read this parameter from the configuration file and then
tries to find the data files in the default directory.

To fix this error, we need to add reading of the innodb_data_home_dir
configuration parameter to the rsync-related SST script.

This patch fixes another problem introduced by the patch for mdev-4817.
The latter changed Item_cond::fix_fields() in such a way that it could
call the virtual method is_expensive(). With the first its call
the method saves the result in Item::is_expensive_cache. For all next
calls the method returns the result from this cache. So if the item
once was determined as expensive the method always returns true.
For subqueries it's not good, because non-optimized subqueries always
is considered as expensive.
It means that the cache should be invalidated after the call of
optimize_constant_subqueries().

In Galera BF (brute force) transactions may not wait for lock requests
and normally BF-transaction would select transaction holding conflicting
locks as a victim for rollback. However, background statistic calculation
transaction is InnoDB internal transaction and it has no thd i.e. it can't be
selected as a victim. If background statistics calculation transaction holds
conflicting locks to statistics tables it will cause BF lock wait long
error message. Correct way to handle background statistics calculation is to
acquire thd for transaction but that change is too big for GA-releases and
there are other reported problems on background statistics calculation.

This fix avoids adding a table to background statistics calculation if

Mysql Bug#56124 bug analog fix using Sys_var_bit.

Restricted output for CREATE USER, GRANT, REVOKE and SET PASSWORD
so that it shows only above keywords but not rest of query i.e.
not user or password.

snprintf returns the number of bytes it wrote (or would have written) NOT
counting the \0 terminal character.
The buffer size it accepts as argument DOES COUNT the \0 character.
Pass the right parameter value.

Used wrong initialization for condition timeout, should have
used set_timespec.

Problem:- Create/drop index was logged into binlog.

Goal:- Operation on temporary table should not be binlog when binlog format
is row.

Solution:-
We should add CF_FORCE_ORIGINAL_BINLOG_FORMAT when there is ddl on temp
table.
For optimize, analyze, repair we wont change anything ,Then will
be logged in binlog , But they also dont throw any error if operation fails
Since slave wont be having any temp table , but these operation on tmp
table will be processed without breaking replication.

For rename we need a different logic MDEV-16728 will solve it.

MDEV-14612 wsrep_sst_mariabackup unnecessarily converts address to host name

MDEV-15442 xtrabackup-v2 SST donor stuck in DONOR/DESYNCED state when…

Do not hold LOCK_thd_data during my_error or WSREP_DEBUG. Similarly,
release LOCK_thd_data before close_thread_tables() call.

          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.

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.

Backport the fix f214d365 to 10.0

   Author: Sergei Golubchik <serg@mariadb.org>
   Date:   Tue Apr 17 00:44:34 2018 +0200

    ASAN error in is_stat_table()

    don't memcmp beyond the first argument's end

    Also: use my_strcasecmp(table_alias_charset), like elsewhere, not memcmp

fix_semijoin_strategies_for_picked_join_order() should set
join->sjm_lookup_tables to be a bitmap of tables inside
SJ-Materialization-Lookup nests.

In this issue we are using derived_with_keys optimization and we are using these keys to do a hash join which is incorrect.
We cannot create keys for dervied tables whose keyparts have types are of BLOB or TEXT type. TEXT or BLOB  columns can only be
indexed over a specified length.

It is not open.

Disks with native 4K sectors need 4K alignment and size for  unbuffered IO
(i.e for files opened with FILE_FLAG_NO_BUFFERING)

Innodb opens redo log with FILE_FLAG_NO_BUFFERING, however it always does
512byte IOs. Thus, the IO on 4K native sectors will fail, rendering
Innodb non-functional.

The fix is to check whether OS_FILE_LOG_BLOCK_SIZE is multiple of logical
sector size, and if it is not, reopen the redo log without
FILE_FLAG_NO_BUFFERING flag.

"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

When the definition of the index used for hash join was created
in create_hj_key_for_table() it could cause memory overwrite
due to a bug that led to an underestimation of the number of
the index component.

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

For the purpose of reporting an error to error log, shutdown thread was
attempting to access current_thd->variables.lc_messages->errmsgs->errmsgs.
Whereas current_thd was NULL.

We should log errors according to global lc_messages setting instead of
session setting.

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).

MDEV-16512 Server crashes in find_field_in_table_ref on 2nd
execution of SP referring to non-existing field

Problem was in the natural join code that it changed TABLE_LIST and
Item_fields but didn't restore changed things if things goes wrong
and was not able to re-execute after failure.
Some of the problems could have been avoided if we would have run
fix_fields before doing natural join transformations.

Fixed by marking functions complete AFTER they had executed, instead at
start.
I had also to change some tests that checked if Item_fields are usable.

This doesn't fix all known problems, but at least avoids some crashes.
What should be done in the near future is to mark the statement in the SP
as 'not re-executable' and force a reparse of it on next execution.

Reviewer: Sergei Petrunia <psergey@askmonty.org>