galera.partition and galera.galera_binlog_stmt_autoinc regularly display
mismatching values for AUTO_INCREMENT columns.

galera.MW-336 often times out while waiting for something in PROCESSLIST.

Also, sort the test names, remove the redundant "galera." prefix and
fix typos in 2 test names.

- Fetch innodb_compression_level from the running server.Add the value
of innodb_compression_level in backup-my.cnf file during backup phase.
So that prepare can use the innodb_compression_level variable from
backup-my.cnf

row_merge_create_index_graph(): Relay the internal state
from dict_create_index_step(). Our caller should free the index
only if it was not copied, added to the cache, and freed.

row_merge_create_index(): Free the index template if it was
not added to the cache. This is a safer variant of the logic
that was introduced in 65070bef in 10.2.

prepare_inplace_alter_table_dict(): Add additional fault injection
to exercise a code path where we have already added an index
to the cache.

row_mysql_handle_errors(): Correct the wrong error handling for
the code DB_FOREIGN_EXCEED_MAX_CASCADE that was introduced in

https://github.com/mysql/mysql-server/commit/c0923d396aef46799883390e9dcf7bbf173e4a03

    commit 35f5429e
    Author: Jimmy Yang <jimmy.yang@oracle.com>
    Date:   Wed Oct 6 06:55:34 2010 -0700

        Manual port Bug #Bug #54582 "stack overflow when opening many tables
        linked with foreign keys at once" from mysql-5.1-security to
        mysql-5.5-security again.

        rb://391 approved by Heikki

No known test case exists for repeating the bug before MariaDB 10.2.
The scenario should be that DB_FOREIGN_EXCEED_MAX_CASCADE is returned,
then InnoDB wrongly skips the rollback to the start of the current
row operation, and finally the SQL layer commits the transaction.
Normally the SQL layer would roll back either the entire transaction or
to the start of the statement. In the faulty scenario, InnoDB would
leave the transaction in an inconsistent state, and the SQL layer could
commit the transaction.

fixes these test failures in ASAN builds (in 10.1 and 10.4):
* main.signal_demo3
* main.sp
* sys_vars.max_sp_recursion_depth_func
* mroonga/storage.foreign_key_delete_existent
* mroonga/storage.foreign_key_delete_nonexistent
* mroonga/storage.foreign_key_insert_existent
* mroonga/storage.foreign_key_update_existent
* mroonga/storage.foreign_key_update_nonexistent
* mroonga/storage.function_command_auto-escape
* mroonga/storage.function_command_select
* mroonga/storage.variable_enable_operations_recording_insert

thd->lex->m_sql_cmd was not cleared between queries.
log_slow_query() could crash (when running mtr --ps) because of this.

I know no test case for this bug in 10.1. So a test case will be
committed separately in 10.2

fts_reset_get_doc(): properly initialize fts_get_doc_t::cache

fts_fetch_index_words(): Restore the initialization len=0.
The test innodb_fts.create in 10.2 would end up in an infinite loop
if this assignment is removed, because a following iteration of the
while() loop would assign zip->zp->avail_in=len with the original value
instead of the 0 that was reset in the previous iteration.

Fix the warnings issued by GCC 8 -Wstringop-truncation
and -Wstringop-overflow in InnoDB and XtraDB.

This work is motivated by Jan Lindström. The patch mainly differs
from his original one as follows:

(1) We remove explicit initialization of stack-allocated string buffers.
The minimum amount of initialization that is needed is a terminating
NUL character.
(2) GCC issues a warning for invoking strncpy(dest, src, sizeof dest)
because if strlen(src) >= sizeof dest, there would be no terminating
NUL byte in dest. We avoid this problem by invoking strncpy() with
a limit that is 1 less than the buffer size, and by always writing
NUL to the last byte of the buffer.
(3) We replace strncpy() with memcpy() or strcpy() in those cases
when the result is functionally equivalent.

Note: fts_fetch_index_words() never deals with len==UNIV_SQL_NULL.
This was enforced by an assertion that limits the maximum length
to FTS_MAX_WORD_LEN. Also, the encoding that InnoDB uses for
the compressed fulltext index is not byte-order agnostic, that is,
InnoDB data files that use FULLTEXT INDEX are not portable between
big-endian and little-endian systems.

row_merge_create_fts_sort_index(): Initialize dict_col_t.

This fixes an access to uninitialized dict_col_t::ind when a debug
assertion in MariaDB 10.4 invokes is_dropped() in
rec_get_converted_size_comp_prefix_low(). Older MariaDB versions
seem to be unaffected by the uninitialized values, but it should
not hurt to initialize everything.

Only starting with MariaDB 10.3.8 (MDEV-16365), InnoDB can actually
handle ALTER IGNORE TABLE correctly when introducing a NOT NULL
attribute to a column that contains a NULL value. Between
MariaDB Server 10.0 and 10.2, we would incorrectly return an error
for ALTER IGNORE TABLE when the column contains a NULL value.

The problem with the InnoDB table attribute encryption_key_id is that it is
not being persisted anywhere in InnoDB except if the table attribute
encryption is specified and is something else than encryption=default.
MDEV-17320 made it a hard error if encryption_key_id is specified to be
anything else than 1 in that case.

Ideally, we would always persist encryption_key_id in InnoDB. But, then we
would have to be prepared for the case that when encryption is being enabled
for a table whose encryption_key_id attribute refers to a non-existing key.

In MariaDB Server 10.1, our best option remains to not store anything
inside InnoDB. But, instead of returning the error that MDEV-17320
introduced, we should merely issue a warning that the specified
encryption_key_id is going to be ignored if encryption=default.

To improve the situation a little more, we will issue a warning if
SET [GLOBAL|SESSION] innodb_default_encryption_key_id is being set
to something that does not refer to an available encryption key.

Starting with MariaDB Server 10.2, thanks to MDEV-5800, we could open the
table definition from InnoDB side when the encryption is being enabled,
and actually fix the root cause of what was reported in MDEV-17320.

1. Always drop merged_for_insert flag on cleanup (there could be errors which prevent TABLE to be assigned)
2. Make more precise cleanup of select parts which was touched

st_select_lex::handle_derived() and mysql_handle_list_of_derived() had
exactly the same implementations.

- Adding a new method LEX::handle_list_of_derived() instead
- Removing public function mysql_handle_list_of_derived()
- Reusing LEX::handle_list_of_derived() in st_select_lex::handle_derived()

Replaced debug to debug_dbug on 10.1 on galera suite. Nothing to do
in wsrep and galera_3nodes suites.

This will allow test binlog.binlog_stm_binlog to pass more often.
Note that this is not a real fix to that test failure.

If we have a 2+ node cluster which is replicating from an async master
and the binlog_format is set to STATEMENT and multi-row inserts are executed
on a table with an auto_increment column such that values are automatically
generated by MySQL, then the server node generates wrong auto_increment
values, which are different from what was generated on the async master.

In the title of the MDEV-9519 it was proposed to ban start slave on a Galera
if master binlog_format = statement and wsrep_auto_increment_control = 1,
but the problem can be solved without such a restriction.

The causes and fixes:

1. We need to improve processing of changing the auto-increment values
after changing the cluster size.

2. If wsrep auto_increment_control switched on during operation of
the node, then we should immediately update the auto_increment_increment
and auto_increment_offset global variables, without waiting of the next
invocation of the wsrep_view_handler_cb() callback. In the current version
these variables retain its initial values if wsrep_auto_increment_control
is switched on during operation of the node, which leads to inconsistent
results on the different nodes in some scenarios.

3. If wsrep auto_increment_control switched off during operation of the node,
then we must return the original values of the auto_increment_increment and
auto_increment_offset global variables, as the user has set. To make this
possible, we need to add a "shadow copies" of these variables (which stores
the latest values set by the user).

https://jira.mariadb.org/browse/MDEV-9519

ib_wqueue_is_empty(): protect ib_list_is_empty() call

Closes #1202

Since MariaDB 10.1.17 the new default values for wsrep_max_ws_rows and wsrep_max_ws_size were set:

wsrep_max_ws_rows

Default Value:
0 (>= MariaDB Galera 10.0.27, MariaDB 10.1.17)
131072 (<= MariaDB Galera 10.0.26, MariaDB 10.1.16)
wsrep_max_ws_size

Default Value:
2147483647 (2GB, >= MariaDB Galera 10.0.27, MariaDB 10.1.17)
1073741824 (1GB, <= MariaDB Galera 10.0.26, MariaDB 10.1.16)

This reverts commit 32629670.
It was checked in by mistake

Failed CREATE OR REPLACE for existing user removes that user
from acl_users array. Thus dependend structures (roles, check_host) must
be rebuilt.

but even if this script called as /bin/mysql_install_db
it is still standard install and scripts are in /usr/share/
(but not in the /share/)
2. fix of bindir path

By pure chance the macro worked in the cases it was used, but
better to get this fixed!

dict_create_foreign_constraints_low(): Clean up the way in
which the error messages are initialized, and ensure that
the table name is always initialized.

Most of the mtr tests in the galera_3nodes suite fail
for a variety of reasons with a variety of errors.

This patch fixes several substantial flaws
in the galera_3nodes suite tests and in the mtr framework
service files, adapting the tests from galera_3nodes
for the current version of MariaDB.

This patch also synchronizes some galera_3nodes-related
files with the latest changes made for MDEV-17835 (v2 patch)
and for MDEV-18379 in other branches (10.2 and 10.3).

Closes #1161

The code path where the table was not being rebuilt during ALTER TABLE
was not covered by the test. Add coverage, and remove the debug assertion
that could fail in this case.

candle.exe's preprocessor flags (-dHaveUpgradeWizard=0 -DHaveInnodb=1)
were not passed correctly to EXECUTE_PROCESS

Fix is to make a list out of the EXTRA_WIX_PREPROCESSOR_FLAGS string,
and use the preprocessor flags list in EXECUTE_PROCESS.