There was a race condition in lock_table_names() which didn't properly test for CREATE OR REPLACE for slaves.


sql/sql_parse.cc:
  Copy create_info flags to thd for lock_table_names()
sql/sql_table.cc:
  Copy create_info flags to thd for lock_table_names()

also a compiler warning.

            main.mysqlslap fail on PPC64

There seem to be a bug on Power8 which doesn't guarantee
a signal to be delivered to waiting thread if broadcast
is called outside of mutex.

For now workaround it by calling broadcast while mutex is
still held.

4229: MDEV-5670: Assertion failure in file buf0lru.c line 2355
      Add more status information if repeatable.

4230: MDEV-5673: Crash while parallel dropping multiple tables under heavy load
      Improve long semaphore wait output to include all semaphore waits
      and try to find out if there is a sequence of waiters.

4233: Fix compiler errors on product build.

4237: Fix too agressive long semaphore wait output and add guard against introducing
      compression failures on insert buffer.

4238: Fix test failure caused by simulated compression failure on
      IBUF_DUMMY table.

This problem affects only debug builds on PPC64.

There are at least two race conditions around
rw_lock_debug_mutex_enter and rw_lock_debug_mutex_exit:

- rw_lock_debug_waiters was loaded/stored without setting
  appropriate locks/memory barriers.
- there is a gap between calls to os_event_reset() and
  os_event_wait() and in such case we're supposed to pass
  return value of the former to the latter.

Fixed by replacing self-cooked spinlocks with system mutexes.
These days system mutexes offer much better performance. OTOH
performance is not that critical for debug builds.

mysql.column_stats wasn't stored/restored properly on big-endian
with histogram_type=DOUBLE_PREC_HB.

Store histogram values using int2store()/uint2korr().

Note that this patch invalidates previously calculated histogram
values on big-endian.

If mysql.innodb_table_stats or mysql.innodb_index_stats is not found or has
unexpected structure output that error only once and no other error for
every table trying to use them. If they do exists, then print fetch or
recalculation errors only once / table or index.

            rpl.rpl_gtid_crash fail on PPC64

GTID order in @@gtid_binlog_pos depends on internal hash order,
so requires to be hidden for stable test output.

line 8473

In case InnoDB index is not found, print the MySQL and InnoDB index
name we were trying to find and all MySQL and InnoDB index names there
is for this table.

ha_innodb.cc line 8473

If index is not found from InnoDB make sure we print what we
were trying to find and all mysql and InnoDB index names there
is for this table.

  Check if the threadpool is available on the system and set HAVE_POOL_OF_THREADS respectively.

Improve OS error messages on Windows.

GTID order in @@gtid_binlog_pos depends on internal hash order,
so requires --replace_result for stable test output.

            misbehave on PPC64

There was a mix of ulong and uint casts/variables which caused
incorrect value to be passed to/retrieved from max_relay_log_size
and sql_slave_skip_counter.

This mix failed to work on big-endian PPC64 where sizeof(int)= 4,
sizeof(long)= 8. E.g. session_var(thd, uint)= 1 will in fact store
0x100000000.

            chain

InnoDB mutex_exit() function calls __sync_test_and_set() to release
the lock. According to manual this function is supposed to create
"acquire" memory barrier whereas in fact we need "release" memory
barrier at mutex_exit().

The problem isn't repeatable with gcc because it creates
"acquire-release" memory barrier for __sync_test_and_set().
ATC creates just "acquire" barrier.

Fixed by creating proper barrier at mutex_exit() by using
__sync_lock_release() instead of __sync_test_and_set().

MDEV-5262, MDEV-5914, MDEV-5941, MDEV-6020: Deadlocks during parallel replication causing replication to fail.

Merge the patches into MariaDB 10.0 main.

With this patch, parallel replication will now automatically retry a
transaction that fails due to deadlock or other temporary error, same as
single-threaded replication.

We catch deadlocks with InnoDB transactions due to enforced commit order. If
T1 must commit before T2 in parallel replication and T1 ends up waiting for T2
inside InnoDB, we kill T2 and retry it later to resolve the deadlock
automatically.

GTID order in @@gtid_binlog_pos depends on internal hash order,
so requires --replace_result for stable test output.

MDEV-5262, MDEV-5914, MDEV-5941, MDEV-6020: Deadlocks during parallel replication causing replication to fail.

Fix a bug discovered in Buildbot valgrind. The logic in checking for slave
init thread completion was reversed, so depending on thread scheduling server
startup could hang.

Also add another variant of SSL valgrind suppression, needed for different
library version.

MDEV-6435: Assertion `m_status == DA_ERROR' failed in Diagnostics_area::sql_errno() with parallel replication

When a MyISAM query is killed midway, the query is logged to the binlog marked
with the error.

The slave does not attempt to run the query, but aborts with a suitable error
message in the error log for the DBA to act on.

In this case, the parallel replication code would check the sql_errno() code,
even no my_error() had been set. In debug builds, this causes an assertion.

Fixed the code to check that we actually have an error set before querying for
an error code.

MDEV-5262, MDEV-5914, MDEV-5941, MDEV-6020: Deadlocks during parallel replication causing replication to fail.

After-review changes. Fix InnoDB coding style issues.

MDEV-5262, MDEV-5914, MDEV-5941, MDEV-6020: Deadlocks during parallel replication causing replication to fail.

Fix small (but nasty) typo.

MDEV-5262, MDEV-5914, MDEV-5941, MDEV-6020: Deadlocks during parallel replication causing replication to fail.

After-review changes.

For this patch in 10.0, we do not introduce a new public storage engine API,
we just fix the InnoDB/XtraDB issues. In 10.1, we will make a better public
API that can be used for all storage engines (MDEV-6429).

Eliminate the background thread that did deadlock kills asynchroneously.
Instead, we ensure that the InnoDB/XtraDB code can handle doing the kill from
inside the deadlock detection code (when thd_report_wait_for() needs to kill a
later thread to resolve a deadlock).

(We preserve the part of the original patch that introduces dedicated mutex
and condition for the slave init thread, to remove the abuse of
LOCK_thread_count for start/stop synchronisation of the slave init thread).

The sql_slave_skip_counter is important to be able to recover replication from
certain errors. Often, an appropriate solution is to set
sql_slave_skip_counter to skip over a problem event. But setting
sql_slave_skip_counter produced an error in GTID mode, with a suggestion to
instead set @@gtid_slave_pos to point past the problem event. This however is
not always possible; for example, in case of an INCIDENT event, that event
does not have any GTID to assign to @@gtid_slave_pos.

With this patch, sql_slave_skip_counter now works in GTID mode the same was as
in non-GTID mode. When set, that many initial events are skipped when the SQL
thread starts, plus as many extra events are needed to completely skip any
partially skipped event group. The GTID position is updated to point past the
skipped event(s).

MDEV-6344: mysqldump issues FLUSH TABLES, which gets written into binlog and replicated

Add a --gtid option (for compatibility, the original behaviour is preserved
when --gtid is not used).

With --gtid, --master-data and --dump-slave output the GTID position (the
old-style file/offset position is still output, but commented out). Also, a
CHANGE MASTER TO master_use_gtid=slave_pos is output to ensure a provisioned
slave is configured in GTID, as requested.

Without --gtid, the GTID position is still output, if available, but commented
out.

Also fix MDEV-6344, to avoid FLUSH TABLES getting into the binlog. Otherwise a
mysqldump on a slave server will silently inject a GTID which does not exist
on the master, which is highly undesirable.

Also fix an incorrect error handling around obtaining binlog position with
--master-data (was probably unlikely to trigger in most cases).

- Add a Sort_priority_queue_sorts status variable.

- Make log_slow_verbosity print "Priority_queue: (Yes|No)" into the slow query log.
  (but we do not add a correspoding column to P_S.*statement* tables).

Analysis: For some reason table stats for a table pointed from a index 
is not initialized. Added additional warning output on this situation
and table stats initialization. This is better than asserting.

Comment out unknown options in SHOW CREATE TABLE unless IGNORE_BAD_TABLE_OPTIONS is used