# Conflicts:
#	libmariadb

This reverts commit 685961a0.

Replicated transaction extra gtid statement on slave failed to specify
an engine gtid_slave_pos name correctly. In case  lower-case-table-names > 0
the InnoDB table name was generated to reproduce the lower-case-table-names=0 version
which is of mixed cases.
In rpl.rpl_mdev12179 test run this triggered a failure to DROP table which
was due to the innodb table handle was not closed:
 InnoDB: Waited XYZ seconds for ref-count on table: `mysql`.`gtid_slave_pos_innodb`
on windows.
The closing issue was caused by having the table registered twice in the table cache,
for its lower- and mixed- case name versions. The DROP-table handler closed only
only one of the cache item to leave the 2nd one active.
(On Linux a failure occurs earlier at attempt to open an expected lower-cased table:

  Last_Error: Error during XID COMMIT: failed to update GTID state in mysql.gtid_slave_pos: 1146: Table 'mysql.gtid_slave_pos_InnoDB' doesn't exist

but the table's name as the message shows is not in the right case).

Fixed with consulting lower-case-table-names when the engine gtid-slave-pos table
is created.
Note the lower-case-table-names=a-value created table will not recognized when next
the lower case option changes to a different value.
In 10.4 a follow-up patch is going to lowercase gtid-slave-pos autocreated table
at once at their origination, and a warning is issued in the 10.3 current patch.

Merging the following features from sql_yacc.yy to sql_yacc_ora.yy:

- system versioning
- column compression
- table value constructor
- spatial predicate WITHIN
- DELETE_DOMAIN_ID

SYSTEM_INVISIBLE or COMPLETELY_INVISIBLE

This commit does multiple things to solve this mdev
1st add field into the parameter of check_column_grant_in_table_ref, so that
we can find out field invisibility.
2nd If field->invisible >= INVISIBLE_SYSTEM skip access check and simple
grant access.

sql_yacc_ora.yy: mering MDEV-13384 "window" seems like a reserved column name but it's not listed as one

Merging MDEV-13384 changes from sql_yacc.yy to sql_yacc_ora.yy

Fixing shift/reduce conflicts introduced by the new system versioning
syntax.

Additionally, fixing old shift/reduce conflicts:

In PREVIOUS/NEXT being identifiers or sequence operations:

  SELECT PREVIOUS FROM t1;
  SELECT PREVIOUS VALUE FOR t1;

In TIME/DATE/TIMESTAMP being literals, functions or identifiers:

  SELECT TIMESTAMP'2001-01-01 10:20:30' FROM t1;
  SELECT TIMESTAMP('2001-01-01 10:20:30') FROM t1;
  SELECT TIMESTAMP FROM t1;

InnoDB does not allow FOREIGN KEY constraints to exist for TEMPORARY TABLE.
InnoDB introduced a dedicated tablespace for temporary tables, and actually
stopped creating persistent metadata and data for temporary tables.

row_table_add_foreign_constraints(): Do not create a persistent
transaction.

dict_create_foreign_constraints_low(): Add the persistent transaction to
the update the foreign key relation in dictionary.

dict_create_foreign_constraints_low(): Remove a duplicated check for
partitioned tables.

MDEV-15979 DELETE HISTORY from a table with transaction-precise versioning causes Assertion `table_list->vers_conditions.type == SYSTEM_TIME_BEFORE' failure

* Fix versioning.truncate,trx_id to create transaction-based tables
* Fix SYSTEM_TIME_BEFORE condition for VERS_TRX_ID

* fixed discovery
* DELETE fix
* federated.test

Closes tempesta-tech/mariadb#490

do "set time_zone='+00:00'" on remote server
after connecting.

temporarily reset local time zone to my_tz_OFFSET0
whenever Field::val_str() or Field::store()
methods are used.

preserve positions if the multi-update join is using tmp table:

* store positions in the tmp table if needed
  JOIN::add_fields_for_current_rowid()

* take positions from the tmp table, not from file->position():
  multi_update::prepare2()

introduce Item_temptable_rowid() that is used to store
table->file->position() in the temporary table record

Reasoning:
- Avoid duplicate comments, both in %token and in the "keyword*" rules.
- The space in the rules will be needed for %prec commands.

Since commit baa5a43d
changed the allocation of log_t::files::file_header_bufs[],
a memory overrun could occur when running with a non-default
setting of innodb_log_files_in_group.

log_t::files::create(): Correctly allocate n_files*2048 + 512
bytes of memory, to be aligned at a 512-byte boundary.

For some reason, two replication tests started failing intermittently
after commit 442a6e6b
changed the InnoDB version number from 5.7.21 to 10.3.7.
There is no obvious reference to INNODB_VERSION or
PLUGIN_AUTH_VERSION or PLUGIN_LIBRARY_VERSION in the replication tests.

Can't repeat issue so I just added the test case

We'll be fixing soon shift-reduce conflicts introduced in the new
10.3 syntax (see MDEV-15818 for details) by defining precedence for
a number of tokens (e.g. TIMESTAMP, TRANSACTION_SYM, TEXT_STRING)
and adding "%prec" directives.

Before doing this, it's better to have the existing precedences set properly,
for easier readability and maintainability.

Details:
- Changing precedence of NOT to its proper position (between AND and IS).
  It was wrong. It worked fine only because the relevant grammar reside
  in different separate rules (expr and predicate).

- Moving NOT2_SYM and BINARY to the same line with NEG and ~
  It worked fine because operators !, BINARY, ~ do not conflict
  to each other.

- Fixing associativity of NOT_SYM, NOT2_SYM, BINARY, COLLATE_SYM
  from "right" to "left". They are not dyadic (operate on a single expression
  only). So "%left" or "%right" is needed only to set precedence,
  while associativity does not matter.
  Note, it would be better to use "%precedence" for these tokens
  instead of "%left" though, but we use an old version of Bison on windows,
  which may not support %precedence yet.

This patch does not change behavior. The generated sql_yacc.cc and
sql_yacc_ora.cc are exactly the same before and after this change.

srv_purge_coordinator_thread(): Wait for all purge worker threads
to actually exit. An analysis of a core dump of a hung 10.3 server
revealed that one srv_worker_thread did not exit, even though the
purge coordinator had exited. This caused kill_server_thread and
mysqld_main to wait indefinitely. The main InnoDB shutdown was
never called, because unireg_end() was never called.

Imported the following test case from mysql to MariaDB

1) innodb.alter_kill
2) innodb.alter_foreign_crash
3) innodb.alter_rename_files
4) innodb.analyze_table
5) Appended the case in innodb-online-alter-gis

Problem:
We keep pinning pages in dict_stats_analyze_index_below_cur(),
but doesn't release these pages. When we have a relative small
buffer pool size, and big innodb_stats_persistent_sample_pages,
there will be no free pages for use.

Solution:
Use a separate mtr in dict_stats_analyze_index_below_cur(),
and commit mtr before return.
Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
RB: 11362

In debug builds of MySQL, there is an configuration variable
that allows an InnoDB log checkpoint to be initiated:

SET GLOBAL innodb_log_checkpoint_now=ON;

Setting this variable while a table-rebuilding ALTER TABLE is executing
may result in an infinite loop.

checkpoint_now_set(): Account for log_sys->append_on_checkpoint->size().
Note that this function contains race conditions, because it is accessing
fields of log_sys without holding log_sys->mutex. We think that this is
acceptable, because this variable only exists for debugging purposes, in
debug builds of MySQL.

RB: 9947
Reviewed-by: Sunny Bains <sunny.bains@oracle.com>

to innodb.innodb-online-alter-gis

Problem:

The function row_build_index_entry_low() takes a dtuple_t object ('row') and
dict_index_t object ('index') as input and returns a new dtuple_t object
('entry') as output.  The dtuple_t object 'row' that is given as input might
have been constructed from a different dict_index_t object (!= index).  So
when accessing the externally stored data of the given 'row' we need to make
use of the correct index object.

Solution:

Store the page size information in the associated row_ext_t object.

rb#6086 approved by Vasil and Jimmy.