For queries like
    "SELECT * FROM INFORMATION_SCHEMA.PARAMETERS
      WHERE SPECIFIC_NAME='proc_name'"
and
    "SELECT * FROM INFORMATION_SCHEMA.ROUTINES
      WHERE ROUTINE_NAME='proc_name'"
there is a possibility to avoid loading of the stored procedure code
and parsing it to retrieve parameters.
If the name of the procedure/function is specified explicitly then
it is possible to filter out routines that do not match at
an early stage.

Queries to INFORMATION_SCHEMA.PARAMETERS and ROUTINES tables are always
performed using full index scan of the mysql.proc primary key
on fields (`db`,`name`,`type`). This can be done in a much more effective
way if `db` and `name` field values can be derived from the WHERE statement,
like here:
  SELECT * FROM INFORMATION_SCHEMA.PARAMETERS
    WHERE SPECIFIC_SCHEMA = 'test' AND SPECIFIC_NAME = 'my_func'
or here:
  SELECT * FROM information_schema.ROUTINES
    WHERE ROUTINE_SCHEMA='test' AND ROUTINE_NAME='my_func'.

In such cases index range scan may be employed instead of full index
scan. This commit makes the server retrieve lookup field values from
the SQL statement and perform index range scan instead of full index
scan if possible.

* MDEV-29142 : Ignore inconsistency warning as we kill cluster
* galera_parallel_apply_3nodes : Disabled because it is unstable
* MDEV-26597 : Add missing code
* galera_sr.galera_sr_ws_size2 : Remove incorrect assertion

followup for e8acec89

The statement 'Verify checksum binlog events.' is confusing. Fix word order to make it clear.

The problem is related to performing operations without switching
wsrep off, this commit fixes this and allows disabled tests.

The problem is related to performing operations without switching
wsrep off, this commit fixes this and allows disabled tests.

Avoid relatively expensive THD::store_globals() for every query in the
threadpool. Use a lighter version instead, that only resets some thread
local storage variables(THD, mysys, PSI), avoids some calculationms
and caches syscall gettid (Linux only) in a thread_local variable.

Also simplify Worker_context use, with RAII.

Adding debug output for key and keyseg flags at ha_myisam::open() time.
So now there are three points of debug output:

1. In the very end of mysql_prepare_create_table()
2. In ha_myisam::create(), after the table2myisam() call
3. In ha_myisan::open(), after the mi_open() call

mi_create(), which is is called between 2 and 3, modifies flags for
some data types, so the output in 2 and 3 is different.

A previous fix in commit efd8af53
failed to cover ALTER TABLE.

PageBulk::isSpaceAvailable(): Check for record heap number overflow.

Reviewer: <wlad@mariadb.com>

MDEV-29707 : Incorrect/bad errno on enabling wsrep_on after setting dummy wsrep_provider on non-Galera build

Fix error message to contain correct errno. This commit was
tested interactively because mtr will notice if you provide
wrong wsrep_provider in config and you may not change
wsrep_provider dynamically.

MDEV-25389 : Assertion `!is_thread_specific || (mysqld_server_initialized && thd)' failed in void my_malloc_size_cb_func(long long int, my_bool)

If wsrep slave thread creation fails for some reason we need to handle
this error correctly and set actual running slave threads accordingly.

MDEV-26597 : Assertion `!wsrep_has_changes(thd) || (thd->lex->sql_command == SQLCOM_CREATE_TABLE && !thd->is_current_stmt_binlog_format_row())' failed.

If repl.max_ws_size is set too low following CREATE TABLE could fail
during commit. In this case wsrep_commit_empty should allow rolling
it back if provider state is s_aborted.

Furhermore, original ER_ERROR_DURING_COMMIT does not really tell anything
clear for user. Therefore, this commit adds a new error
ER_TOO_BIG_WRITESET. This will change some test cases output.

MDEV-27123 : auto_increment_increment and auto_increment_offset reset to 1 in current session after alter table on auto-increment column

Problem was that in ALTER TABLE execution variables were set
to 1 even when wsrep_auto_increment_control is OFF. We should
set them only when wsrep_auto_increment_control is ON.

In test user has set WSREP_ON=OFF this causes streaming replication
recovery to fail and this caused call to unireg_abort(). However,
this call is not necessary and we can let transaction to fail. Naturally,
if real user does this he needs to bootstrap his cluster.

This message would always have been invoked on ptr=NULL.

after 6b685ea7 one can no longer violate the locking protocol
by invoking thd_get_ha_data() on some other thread without
protecting that with a mutex

10.5 part: test cases and comments.
The code is in the merge commit 74fe1c44

When f.ex. table is partitioned by HASH(a) and we rename column `a' to
`b' partitioning filter stays unchanged: HASH(a). That's the wrong
behavior.

The patch updates partitioning filter in accordance to the new columns
names. That includes partition/subpartition expression and
partition/subpartition field list.