The code in binlog group commit around wait_for_commit that controls commit
order, did the wakeup of subsequent commits early, as soon as a following
transaction is put into the group commit queue, but before any such commit has
actually taken place. This causes problems with too early wakeup of
transactions that need to wait for prior to commit, but do not take part in
the binlog group commit for one reason or the other.

This patch solves the problem, by moving the wakeup to happen only after the
binlog group commit is completed.

This requires a new solution to ensure that transactions that arrive later
than the leader are still able to participate in group commit. This patch
introduces a flag wait_for_commit::commit_started. When this is set, a waiter
can queue up itself in the group commit queue.

This way, effectively the wait_for_prior_commit() is skipped only for
transactions that participate in group commit, so that skipping the wait is
safe. Other transactions still wait as needed for correctness.

The code that handles free lists of various objects passed to worker threads
in parallel replication handles freeing in batches, to avoid taking and
releasing LOCK_rpl_thread too often. However, it was possible for freeing to
be delayed to the point where one thread could stall the SQL driver thread due
to full queue, while other worker threads might be idle. This could
significantly degrade possible parallelism and thus performance.

Clean up the batch freeing code so that it is more robust and now able to
regularly free batches of object, so that normally the queue will not run full
unless the SQL driver thread is really far ahead of the worker threads.

The bug occured in parallel replication when re-trying transactions that
failed due to deadlock. In this case, the relay log file is re-opened and the
events are read out again. This reading requires a format description event of
the appropriate version. But the code was using a description event stored in
rli, which is not thread-safe. This could lead to various rare races if the
format description event was replaced by the SQL driver thread at the exact
moment where a worker thread was trying to use it.

The fix is to instead make the retry code create and maintain its own format
description event. When the relay log file is opened, we first read the format
description event from the start of the file, before seeking to the current
position. This now uses the same code as when the SQL driver threads starts
from a given relay log position. This also makes sure that the correct format
description event version will be used in cases where the version of the
binlog could change during replication.

In parallel replication, threads can do two different waits for a prior
transaction. One is for the prior transaction to start commit, the other is
for it to complete commit.

It turns out that the same PSI_stage_info message was errorneously used in
both cases (probably a merge error), causing SHOW PROCESSLIST to be
misleading.

Fix by using correct, distinct message in each case.

In parallel replication, the wait_for_commit facility is used to ensure that
events are written into the binlog in the correct order. This is handled in an
optimised way in the binlogging group commit code.

However, some statements, for example GRANT, are written directly into the
binlog, outside of the group commit code. There was a bug that this direct
write does not correctly wait for the prior transactions to have been written
first, which allows f.ex. GRANT to be written ahead of earlier transactions.

This patch adds the missing wait_for_prior_commit() before writing directly to
the binlog.

However, the problem is still there, although the race is much less likely to
occur now. The problem is that the optimised group commit code does wakeup of
following transactions early, before the binlog write is actually done. A
woken-up following transaction is then allowed to run ahead and queue up for
the group commit, which will ensure that binlog write happens in correct order
in the end. However, the code for directly written events currently bypass
this mechanism, so they get woken up and written too early.

This will be fixed properly in a later patch.

The real bug was that open_tables() returned error in case of
thd->killed() without properly calling thd->send_kill_message()
to set the correct error. This was fixed some time ago.

So remove the, now redundant, extra checks for thd->is_error(),
possibly allowing to catch in debug builds more incorrect
error handling cases.

In SAFE_MUTEX builds, reset the wait_for_commit mutex (destroy and
re-initialise), so that SAFE_MUTEX lock order check does not become
confused when the mutex is re-used for a different purpose.

setting of innodb_io_capacity_max

(a) Changed the behaviour so that if you set innodb_io_capacity to a 
value > innodb_io_capacity_max that the value is accepted AND 
that innodb_io_capacity_max = innodb_io_capacity * 2.

(b) If someone wants to reduce innodb_io_capacity_max and 
reduce it below innodb_io_capacity then innodb_io_capacity 
should be reduced to the same level as innodb_io_capacity_max.

In both cases give a warning to user.

Analysis: InnoDB error monitor is responsible to call every second
sync_arr_wake_threads_if_sema_free() to wake up possible hanging
threads if they are missed in mutex_signal_object. This is not
possible if error monitor itself is on mutex/semaphore wait. We
should avoid all unnecessary mutex/semaphore waits on error monitor.
Currently error monitor calls function buf_flush_stat_update()
that calls log_get_lsn() function and there we will try to get
log_sys mutex. Better, solution for error monitor is that in
buf_flush_stat_update() we will try to get lsn with
mutex_enter_nowait() and if we did not get mutex do not update
the stats.

Fix: Use log_get_lsn_nowait() function on buf_flush_stat_update()
function. If returned lsn is 0, we do not update flush stats.
log_get_lsn_nowait() will use mutex_enter_nowait() and if
we get mutex we return a correct lsn if not we return 0.

on work-amd64-valgrind.

Fixed issue by finding out first the current used priority
for both treads and using that seeing did we really change
the priority or not.

MDEV-7073 main.information_schema and main.information_schema_all_engines fail in buildbot on a build without perfschema

main.information_schema: added a condition to the query to exclude perfschema tables
main.information_schema_all_engines: added a call to the include file to check for the presence of perfschema

MDEV-7072 mroonga/wrapper.version_56_or_later_performance_schema fails in buildbot on a build without perfschema

Added a call for the include file to check for the presence of perfschema

MDEV-7071 Spider tests fail due to an unknown option --skip-performance-schema on a build without perfschema

Made the option --loose

Added a call for the include file

table names are case-insensitive.

The bug is not very important per se, but it was helpful to move
Item_func_strcmp out of Item_bool_func2 (to Item_int_func),
for the purposes of "MDEV-4912 Add a plugin to field types (column types)".

The test runs a query in one thread, then in another queries the processlist
and expects to find the first thread in the COM_SLEEP state. The problem is
that the thread signals completion to the client before changing to COM_SLEEP
state, so there is a window where the other thread can see the wrong state.

A previous attempt to fix this was ineffective. It set a DEBUG_SYNC to handle
proper waiting, but unfortunately that DEBUG_SYNC point ended up triggering
already at the end of SET DEBUG_SYNC=xxx, so the wait was ineffective.

Fix it properly now (hopefully) by ensuring that we wait for the DEBUG_SYNC
point to trigger at the end of the SELECT SLEEP(), not just at the end of
SET DEBUG_SYNC=xxx.

Use fn_ext2() to get the file extension from last occurrence
of FN_EXTCHAR ('.') instead. Also made some cosmetic changes
in mysys/mf_fn_ext.c.

The function  get_column_range_cardinality() returned a wrong result for any column
containing only null values.

(Backport to 5.3)
(Attempt #2)
- Don't attempt to use BKA for materialized derived tables. The 
  table is neither filled nor fully opened yet, so attempt to 
  call handler->multi_range_read_info() causes crash.

(Backport to 5.3)
(variant #2, with fixed coding style)
- Make Mrr_ordered_index_reader::resume_read() restore index position 
  only if it was saved before with Mrr_ordered_index_reader::interrupt_read().

- TABLE::create_key_part_by_field() should not set PART_KEY_FLAG in field->flags
  = The reason is that it is used by hash join code which calls it to create a hash
    table lookup structure. It doesn't create a real index.
  = Another caller of the function is TABLE::add_tmp_key(). Made it to set the flag itself.

- The differences in join_cache.result could also be observed before this patch: one
  could put "FLUSH TABLES" before the queries and get exactly the same difference.

Field::selectivity should be set for all fields used in range conditions.

Fix failure seen on dict_foreign_remove_partial().