A prepared backup from Mariabackup does not really need to contain any
redo log file, because all log will have been applied to the data files.

When the user copies a prepared backup to a data directory (overwriting
existing files), it could happen that the data directory already contained
redo log files from the past. mariabackup --copy-back) would delete the
old redo log files, but a user’s own copying script might not do that.
To prevent corruption caused by mixing an old redo log file with data
files from a backup, starting with MDEV-13311, Mariabackup would create
a zero-length ib_logfile0 that would prevent startup.

Actually, there is no need to prevent InnoDB from starting up when a
single zero-length file ib_logfile0 is present. Only if there exist
multiple data files of different lengths, then we should refuse to
start up due to inconsistency. A single zero-length ib_logfile0 should
be treated as if the log files were missing: create new log files
according to the configuration.

open_log_file(): Remove. There is no need to open the log files
at this point, because os_file_get_status() already determined
the size of the file.

innobase_start_or_create_for_mysql(): Move the creation of new
log files a little later, not when finding out that the first log
file does not exist, but after finding out that it does not exist
or it exists as a zero-length file.

Rename the 10.2-specific configuration option innodb_unsafe_truncate
to innodb_safe_truncate, and invert its value.

The default (for now) is innodb_safe_truncate=OFF, to avoid
disrupting users with an undo and redo log format change within
a Generally Available (GA) release series.

While MariaDB Server 10.2 is not really guaranteed to be compatible
with Percona XtraBackup 2.4 (for example, the MySQL 5.7 undo log format
change that could be present in XtraBackup, but was reverted from
MariaDB in MDEV-12289), we do not want to disrupt users who have
deployed xtrabackup and MariaDB Server 10.2 in their environments.

With this change, MariaDB 10.2 will continue to use the backup-unsafe
TRUNCATE TABLE code, so that neither the undo log nor the redo log
formats will change in an incompatible way.

Undo tablespace truncation will keep using the redo log only. Recovery
or backup with old code will fail to shrink the undo tablespace files,
but the contents will be recovered just fine.

In the MariaDB Server 10.2 series only, we introduce the configuration
parameter innodb_unsafe_truncate and make it ON by default. To allow
MariaDB Backup (mariabackup) to work properly with TRUNCATE TABLE
operations, use loose_innodb_unsafe_truncate=OFF.

MariaDB Server 10.3.10 and later releases will always use the
backup-safe TRUNCATE TABLE, and this parameter will not be
added there.

recv_recovery_rollback_active(): Skip row_mysql_drop_garbage_tables()
unless innodb_unsafe_truncate=OFF. It is too unsafe to drop orphan
tables if RENAME operations are not transactional within InnoDB.

LOG_HEADER_FORMAT_10_3: Replaces LOG_HEADER_FORMAT_CURRENT.

log_init(), log_group_file_header_flush(),
srv_prepare_to_delete_redo_log_files(),
innobase_start_or_create_for_mysql(): Choose the redo log format
and subformat based on the value of innodb_unsafe_truncate.

The test needs to be run with rocksdb_flush_log_at_trx_commit=1, otherwise
the changes do not survive a crash.

Add wait on second node.

Ensure that no redo log checkpoint occurs in a critical section
of a recovery test.

if thread specific memory is requested and current_thd is NULL.

Leave DBUG_ASSERT() in place, to check in DBUG version.

Make the testcase stable

The bug appears as a slave SQL thread hanging in
rpl_parallel_thread_pool::get_thread() while there are no slave worker
threads to awake it.

The reason of the hang is that at the parallel slave worker pool
activation the being stared SQL thread could read the worker pool size
concurrently with pool deactivation. At reading the SQL thread did not
employ necessary protection from a race.

Fixed with making the SQL thread at the pool activation first
to grab the same lock as potential deactivator also does prior
to access the pool size.

			table for purge thread

Problem:
=======
	Purge tries to fetch mdl lock for the whole table even though it tries
to open one of the partition. But table name length was wrongly set to indicate
the partition name too.

Solution:
========
- Table name length should identify the table name only not the partition name.

           derived table / view by equality

Now rows of a materialized derived table are always put into a
temporary table before join operation. If BNLH is used to join this
table with the result of a partial join then both operands of the
join are actually put into main memory. In most cases this is not
efficient.
We could avoid this by sending the rows of the derived table directly
to the join operation. However this kind of data flow is not supported
yet.
Fixed by not allowing usage of hash join algorithm to join a materialized
derived table if it's joined by an equality predicate of the form
f=e where f is a field of the derived table.

           derived table / view by equality

Now rows of a materialized derived table are always put into a
temporary table before join operation. If BNLH is used to join this
table with the result of a partial join then both operands of the
join are actually put into main memory. In most cases this is not
efficient.
We could avoid this by sending the rows of the derived table directly
to the join operation. However this kind of data flow is not supported
yet.
Fixed by not allowing usage of hash join algorithm to join a materialized
derived table if it's joined by an equality predicate of the form
f=e where f is a field of the derived table.

Amend previous patch, so it works in all cases (also for "change user"
command, and for RESET CONNECTION in 10.3)

MDEV-17313 Data race in ib_counter_t

This warning come from a copy() operation of type:
memcpy(ptr, ptr+A, B), which is safe but produces a warning
when run with valgrind.

To avoid the warning, I added copy_or_move() method which uses
memmove() instead of memcpy().

In 10.3 the change in item_strfunc::Item_func_concat() has to be mirroed
in Item_func_concat_oracle() to avoid future valgrind warnings.

This is a regression caused by
commit 73af8af0
(MDEV-15325 Incomplete validation of missing tablespace during recovery).

If the recv_sys->addr_hash hash table ran out of memory, we would
have to do crash recovery in multiple passes. If some tablespaces were
missing, after the MDEV-15325 fix we would rescan the remaining redo log.
But, we could incorrectly reset the "rescan" flag. Because of this, we
would fail to apply some of the oldest redo log records to the data files.
(The recv_sys->addr_hash would only contain records from the latest
redo log scan batch.)

Fix:

After checking for missing tablespaces, reset the flag rescan=true,
so that all redo log records will be re-read and applied.

pthread_detach_this_thread() was intended to be defined to something
meaningful only on some ancient unixes, which don't have
pthread_attr_setdetachstate() defined. Otherwise, on normal unixes,
threads are created detached in the first place.

This was broken in 0f01bf26 so that
we started calling pthread_detach() for already detached threads.
Intention was to detach aria checkpoint thread.

However in 87007dc2 aria service threads
were made joinable with appropriate handling, which makes breaking
revision unneccessary.

Revert remnants of 0f01bf26, so that
pthread_detach_this_thread() is meaningful only on some ancient unixes
again.

SLES11 can't build currently latest Galera library version.

Add wait until cluster has correct number of nodes.

Output API function name, exception name, exception text

ib_counter_t: make all reads/writes to m_counter relaxed atomical

MDEV-16656: DROP DATABASE crashes the Galera Cluster

When converting table identifiers to a new format,
some tables can be renamed twice, which subsequently
leads to the appearance of "false" auxiliary tables
belonging to another main (parent) table (which does
not actually have auxiliary tables).

This is because the table number is repeatedly added
to the aux_tables_to_rename vector inside the function
fts_check_and_drop_orphaned_tables.

To correct this error, we must add a check for the
occurrence of the table number in the aux_tables_to_rename
vector before adding a new element.

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

			|| node->vcol_info.is_used()' failed

- Purge thread can acquire mdl lock while initializing the mysql template.
Set the vcol_info information before acquiring mdl lock.

- Purge thread doesn't need to use the virtual column info even though it is
requested. In that case, reset the virtual column info.

rw_lock_x_lock_wait_func(): remove duplicated logic added in incorrect merge

Affected counters are affected by InnoDB monitor. But they aren't stable and thus
can not be realiably tested.