With INFORMATION_SCHEMA set as the default database the check that a table
referred in the processed query is defined in INORMATION_SCHEMA must
be postponed until all CTE names can be identified.

Fixed by adding more rows to a table

Other things:
- Speed up index_merge tests 20% by adding begin/commit around loops that
  generated rows.

Normally, InnoDB will create temporary table names of the form
#sql-ibNNNN, and with innodb_safe_truncate=OFF, #sql-ibNNNN-MMMM.

If InnoDB crash recovery was needed, the InnoDB function srv_start()
would invoke extra validation, reading something from every InnoDB
data file. This should be unnecessary now that MDEV-14717 made
RENAME operations crash-safe inside InnoDB (which can be
disabled in MariaDB 10.2 by setting innodb_safe_truncate=OFF).

dict_check_sys_tables(): Skip tables that would be dropped by
row_mysql_drop_garbage_tables(). Perform extra validation only
if innodb_safe_truncate=OFF, innodb_force_recovery=0 and
crash recovery was needed.

dict_load_table_one(): Validate the root page of the table.
In this way, we can deny access to corrupted or mismatching tables
not only after crash recovery, but also after a clean shutdown.

For some reason, GCC 8 did not issue warnings for all such comparisons.

row_is_mysql_tmp_table_name(): Replaced with
dict_table_t::is_temporary_name() and table_name_t::is_temporary().

table_name_t: Add constructors.

In MariaDB, InnoDB tables will always contain DATA_N_SYS_COLS = 3
columns, 2 or 3 of which are present in the clustered index.
We remove the predicate that was added in MySQL 5.7 as part of WL#7682.

InnoDB and XtraDB had redundant assertions for checking that
function parameters that were declared as nonnull were not NULL.

it was supposed to be `*(p-1)` not `*p-1`
(the crash happens if `*p==0`)

in particular, don't search for libjemalloc.a, which is only
needed for tokudb's ftcxx tests, when the tests aren't going
to be built.

`zypper install krb5-devel` installs executables outside of $PATH.
It also installs /etc/profile.d/krb5.sh that is sourced by a new
shell to add the new location to the $PATH. But this doesn't affect
the current shell.

Now decent Linux distros remind the user to run `. /etc/profile`
to reload paths in such a case. SUSE doesn't and for a good reason -
it doesn't work there. Because SUSE sets PROFILEREAD=true in the
environment and /etc/profile does not do anything.

By this point, one should not really expect `unset PROFILEREAD` to help,
and it does not - PROFILEREAD is readonly, and cannot be unset.

Apparently SUSE really *really* wants you to re-login between installing
MariaDB build dependencies and actually running the rpmbuild.

Which we cannot do it buildbot. And it would look very user-un-friendly
in the Build Instructions section of the manual.

So, we work around it - by adding SUSE krb5 path to the search list.

THIS IS SUSEEEEEE!!!

Filter out most common file types from automatic dependency collection.
This makes `make package`  in centos73 VM three times faster

MariaDB does support InnoDB tables with no stored columns.
(They are necessarily empty.)

On Microsoft Windows, InnoDB writes the path separator \ to the
redo log file, while on all other platforms, / is being used.

fil_name_parse(): Normalize the parsed path separators to the
native format. This allows backups or data sets to be portable
between Windows and other systems.

This is follow-up for commit 619d22dd
to fix the cmake -DWITH_EMBEDDED_SERVER build.

MariaDB before MDEV-5800 in version 10.2.2 did not support
indexed virtual columns. Non-persistent virtual columns were
hidden from storage engines. Only starting with MDEV-5800, InnoDB
would create internal metadata on virtual columns.

Similar to what was done in MDEV-18084, MDEV-18090, MDEV-18960, we adjust
one more code path for the old tables.

innobase_build_col_map(): Allocate space for virtual columns in col_map[]
but leave the entries at ULINT_UNDEFINED, noting that the virtual columns
were missing before the table was being rebuilt.

InnoDB includes 3 parsers, which use 3 lexical analyzers that
are generated with flex. Flex versions before 2.6 emitted
the keyword "register", which is deprecated in C++17.

The lexical analyzers were regenerated as follows:

for s in storage/innobase storage/xtradb
do
	(cd "$s"/pars; ./make_flex.sh)
	touch "$s"/fts/*.l
	make -C "$s"/fts -f Makefile.query
done

The MDEV-11738/MDEV-11581 fix was supposed to add the column
ROTATING_OR_FLUSHING to the INFORMATION_SCHEMA table
INNODB_TABLESPACES_ENCRYPTION, but it also added that column to
INNODB_TABLESPACES_SCRUBBING in InnoDB (not XtraDB).

The extra column was never initialized. We will remove it,
because key rotation has nothing to do with the scrubbing of
tablespace data.

It turns out, moving it to rocksdb_stress test suite is not that easy.

rec_get_offsets() was previously called in a btr_cur_optimistic_update()

When HAVE_YASSL is defined (due to cmake -DWITH_SSL=bundled
or otherwise), mysys_ssl/my_crypt.cc will #include "yassl.cc"
from the same directory.

When MariaDB 10.2 or later is compiled with GCC 8 and optimizations
are enabled, then the check
  if (iv)
in EVP_CipherInit_ex() can be wrongly optimized away.
The reason appears to be that __attribute__((nonnull)) is attached
to the variable iv, because there is a (no-op) call
memcpy(oiv, iv, ivlen=0) earlier in the code path.

It is possible that this started failing after the code was
refactored in MDEV-10332 (MariaDB 10.2.6). In MariaDB 10.1,
there is a similar memcpy() call in MyCTX_nopad::init(),
but the code appears to work fine.

The cause for this was fix MDEV-15372, which was trying to speed up
the parallel slave.

Part#1: Do not attempt the "optimization" for transactions that are not
replication slave workers.

Problem:
========
When attempting to delay a Slave attached with GTID, there appears to be an
extra delay applied initially. For example, this output reflects a Slave that is
already delayed by 43200 seconds. When switching to GTID replication,
replication is paused until SQL_Remaining_Delay counts down to 0:

CHANGE MASTER TO master_use_gtid=current_pos; CHANGE MASTER TO
MASTER_DELAY=43200;

Seconds_Behind_Master: 44847
Using_Gtid: Current_Pos
SQL_Delay: 43200
SQL_Remaining_Delay: 43089
Slave_SQL_Running_State: Waiting until MASTER_DELAY seconds after master
executed event

Analysis:
=========
When slave initiates a GTID based connection request to master, the master sends
two GTID_LIST events.  The first one is actual GTID_LIST event and the second
one is a fake GTID_LIST event. This is sent by master to provide its current
binlary log file position. The fake GTID_LIST events will have their ev->when=0.
'when' (the timestamp) is set to 0 so that slave could distinguish between real
and fake Rotate events.

On slave side when MASTER_DELAY is configured to "X" the applier will ensure
that there is a time delay of "X" seconds before the event is applied.

General behaviour of MASTER_DELAY example:-

Master
timestamp of event e1=10
timestamp of event e2=11

On slave MASTER_DELAY=5
Event e1 will be applied at = 15
e2 will be applied at =16

In bug scenario:-

On Master: With GTIDs
timestamp of event e1=10
timestamp of event e2=0

On Slave:
e1 will be applied at = 10 + 5 =15
For e2, since "e2->when=0" e2->when is set to current timestamp.
i.e since the e2->when and current timestamp on slave is the same applier waits
for additional master_delay=5 seconds. the ev->when contributes to
"rli->last_master_timestamp".

rli->last_master_timestamp= ev->when + (time_t) ev->exec_time;

Fake events should not update the "ev->when" to "current timestamp" on slave.

Fix:
===
Remove the assignment of current timestamp to "ev->when" when "ev->when=0".