trx_undo_page_report_modify(): For SPATIAL INDEX, keep logging
updated off-page columns twice, so that
the minimum bounding rectangle (MBR) will be logged.
Avoiding the redundant logging would require larger changes
to the undo log format.

row_build_index_entry_low(): Handle SPATIAL_UNKNOWN more robustly,
by refusing to purge the record from the spatial index.
We can get this code when processing old undo log from 10.2.10 or
10.2.11 (the releases affected by MDEV-14799, which was a regression
from MDEV-14051).

The InnoDB background tasks can modify tables while LOCK TABLES...WRITE
is in effect. The purge of InnoDB history always worked like this in
MariaDB, but in MySQL 5.7 it sometimes yields to LOCK TABLES.

Also, make gcol.innodb_virtual_index run the purge for an UPDATE
before DROP TABLE is executed.

This is to be able to better track where things goes wrong

Make rpl_ctype_latin1 more portable by printing names in hex
Also only run if lower_case_table_names is 0, as this affects the result

up fix for MDEV-12458

trx_undo_rec_get_partial_row(): When the PRIMARY KEY includes a
column prefix of an externally stored column, the already parsed
part of the undo log record may contain a reference to
an off-page column. This is the case in the bug58912 test in
innodb.innodb.

This is a regression caused by MDEV-14051 'Undo log record is too big.'

Purge in the secondary index is wrongly skipped in
row_purge_upd_exist_or_extern() because node->row only does not contain all
indexed columns.

trx_undo_rec_get_partial_row(): Add the parameter for node->update
so that the updated columns will be copied from the initial part
of the undo log record.

Disabled warnings for directory option as this is depending on compilation
options.

Code in QUICK_RANGE_SELECT::init_ror_merged_scan() could theoretically
have caused crashes if this was ever called from an update or delete

This also found a bug in the vcol/range.result. file.

Added a system variabe rocsdb_git_hash to MyRocks which tell us the version of RocksDB being used

Currently explain format=json does not show the order direction of fields used during filesort.
This patch would remove this limitation

             Locked_tables_list::unlock_locked_tables

Similarly to regular DROP TABLE, don't leave locked tables mode if CREATE OR
REPLACE dropped temporary table but failed to cerate new one.

The problem is that there's no track of which temporary table was "locked" by
LOCK TABLES.

Window definitions are resolved during fix fields. Updating used tables
for window functions must be done after all window functions have had a
chance to be resolved.

There was an additional problem with the implementation: expressions that
contained window functions never updated the expression's used tables.
To fix both these issues, make sure to call "update_used_tables" on all
items that contain window functions after we have passed through all
items.

cherry-pick e6ce97a5

* don't use Env module in tests, use $ENV{xxx} instead
* collateral changes:
** $file in the error message was unset
** $file in the other error message was unset too :)
** source file arguments are conventionally upper-cased
** abort the test (die) on error, don't just echo/exit

for a query that uses CTE

The first reference to a CTE in the processed query uses the unit
built by the parser for the CTE specification. This unit is
considered as the specification of the derived table created for
the first reference of the CTE. This requires some transformation of
the original query tree: the unit of the specification must be moved
to a new position as a slave of the select where the first reference
to the CTE occurs. The transformation is performed by the function
st_select_lex_node::move_as_slave(). There was an obvious bug in this
function. As a result of this bug in many cases the moved unit turned
out to be lost in the query tree. This could cause different problems.
In particular the prepared statements for queries that used CTEs could
miss cleanup for some selects that was performed at the end of the
preparation/execution of the PSs. If such cleanup is not done for a PS
the next execution of the PS causes an assertion abort or a crash.

If translation table present when we materialize the derived table then
change it to point to the materialized table.

Added debug info to see really what happens with what derived.

MDEV-14249 Wrong character set info of Query_log_event and the query in Query_log_event constructed by different charsets cause error when slave apply the event.

MDEV-14026 ALTER TABLE ... DELAY_KEY_WRITE=1 creates table copy for partitioned MyISAM table with DATA DIRECTORY/INDEX DIRECTORY options

set data_file_name and index_file_name in HA_CREATE_INFO
before calling check_if_incompatible_data()

don't allocate them on THD::mem_root on every init(HA_STATUS_CONST) call,
do it once in open() (because they don't change) on TABLE::mem_root
(so they stay valid until the table is closed)

PKG_CONFIG does not really work on Windows, Strawberry perl's uses mingw
libraries, which VS compiler cannot use,

BOOST not used.

Tests main.query_cache_debug and main.mdev-504 timed out on debug build
at 2 minutes so increase the timeout to 4 minutes.

Overall build time was 30 min 44 seconds so plenty of time currently.
Signed-off-by: Daniel Black <daniel@linux.vnet.ibm.com>

Signed-off-by: Daniel Black <daniel.black@au.ibm.com>

fix 011497bd

in RPM and DEB: storage engine packages must require the server
package of exactly correct version.

Problem:- Gtid are not transferred in Galera Cluster.

Solution:- We need to transfer gtid in the case on either when cluster is
slave/master in async replication. In normal Gtid replication gtid are generated on
recieving node itself and it is always on sync with other nodes. Because galera keeps
node in sync , So all nodes get same no of event groups. So the issue arises when
say galera is slave in async replication.
A
|    (Async replication)
D <-> E <-> F  {Galera replication}
So what should happen is that all node should apply the master gtid but this does
node happen, becuase node E, F does not recieve gtid from D in write set , So what E(or F)
does is that it applies wsrep_gtid_domain_id, D server-id , E gtid next seq no. This
generated gtid does not always work when say A has different domain id.

So In this commit, on galera node when we see that this event is recieved from master
we simply write Gtid_Log_Event in write_set and send it to other nodes.