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().

Merged Facebook commit ec1aac68c74f3c1e558d057c4c9fcfe6edbbea93
authored by Steaphan Greene from https://github.com/facebook/mysql-5.6

In C++11, "" is not parsed as before.  So "A""B" is not the same as "AB".
Instead, whitespace is required, like: "A" "B"

Merged Facebook commit dd2d11be7aaf3be270e740fb95cbc4eacb52f4d7
authored by Rongrong Zhong from https://github.com/facebook/mysql-5.6

This fixes MySQL Bug #68220 innodb_rows_updated is misleading on slave
http://bugs.mysql.com/bug.php?id=68220

Added innodb_system_rows_read/inserted/updated/deleted counters
that are the equivalent of innodb_rows_* but that only account for
changes made to system databases (mysql, information_schame and
preformance_schema). These counters will be used on slaves to
differentiated the updates made on system databases from those made on
user databases.

innodb_rows_* status counters are not updated when innodb_system_rows_*
are updated.

https://github.com/facebook/mysql-5.6/commit/dd2d11be7aaf3be270e740fb95cbc4eacb52f4d7