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

Reject huge frms at CREATE TABLE, not when it - successfully written - is being opened.
Also raise the frm size limit from 256K to 512K

https://code.launchpad.net/~chewi/maria/mysql-fix-bug61340/+merge/217351

Analysis: sync array output function, should make sure that all
used pointers are valid before using them.

Merge revision 4225 from lp:maria/5.5.

Follow-up patch. The original patch added an extra argument to the
rli->report() function, however it was forgotten to adjust the calls
accordingly in a few places.

This patch updates the remaining calls as needed. In files log_event_old.cc
and rpl_record_old.cc, it just adds NULL, since this is only for old event
formats from ancient master servers, which would not have any GTID information
to add to the error messages in any case.

than with InnoDB plugin

Fix: os0file.h in XtraDB had OS_AIO_N_PENDING_IOS_PER_THREAD 256
when on InnoDB it is OS_AIO_N_PENDING_IOS_PER_THREAD 32. Changed
XtraDB also to use 32.

then can't ALTER TABLE any more.

Fix for InnoDB storage engine.

ALTER TABLE any more.

        Tests were merged.
        As the implementation is different, the 'internal debugging' part
        was not merged, only a stub for it created.

These tests use search_pattern_in_file.inc to search the error log for
expected output. However, search_pattern_in_file.inc by default searched only
the first 50000 bytes, so if the error log grew too big the tests would fail.

This patch extends search_pattern_in_file.inc with an option to specify how
much of the file to search, and whether to search from the start of the file
or from the end. Then the rpl.rpl_checksum and rpl.rpl_gtid_errorlog test
cases are fixed to search the last 50000 bytes of the error log, which will
work no matter how large prior tests have made it.

MDEV-6386: Assertion `thd->transaction.stmt.is_empty() || thd->in_sub_stmt || (thd->state_flags & Open_tables_state::BACKUPS_AVAIL)' fails with parallel replication

The direct cause of the assertion was missing error handling in
record_gtid(). If ha_commit_trans() fails for the statement commit, there was
missing code to catch the error and do ha_rollback_trans() in this case; this
caused close_thread_tables() to assert.

Normally, this error case is not hit, but in this case it was triggered due to
another bug: When a transaction T1 fails during parallel replication, the code
would signal following transactions that they could start to run without
properly marking the error condition. This caused subsequent transactions to
incorrectly start replicating, only to get an error later during their own
commit step. This was particularly serious if the subsequent transactions were
DDL or MyISAM updates, which cannot be rolled back and would leave replication
in an inconsistent state.

Fixed by 1) in case of error, only signal following transactions to continue
once the error has been properly marked and those transactions will know not
to start; and 2) implement proper error handling in record_gtid() in the case
that statement commit fails.

Use user's ip address when verifying privileges for SET ROLE (just like check_access() does)

If replication breaks in GTID mode, it is not trivial to determine the GTID of
the failing event group. This is a problem, as such GTID is needed eg. to
explicitly set @@gtid_slave_pos to skip to after that event group, or to
compare errors on different servers, etc.

Fix by ensuring that relevant slave errors logged to the error log include the
GTID of the event group containing the problem event.

This is MySQL Bug#59123. The message string stored in an INCIDENT event was
not zero-terminated. This caused any following checksum bytes (if enabled on
the master) to be output to the error log as trailing garbage when the message
was printed to the error log.

Backport the patch from MySQL 5.6:

  revno: 2876.228.200
  revision-id: zhenxing.he@sun.com-20110111051323-w2xnzvcjn46x6h6u
  committer: He Zhenxing <zhenxing.he@sun.com>
  timestamp: Tue 2011-01-11 13:13:23 +0800
  message:
    BUG#59123 rpl_stm_binlog_max_cache_size fails sporadically with found warnings

Also add a test case.

MySQL 5.6 implemented WL#344, which is about a MASTER_DELAY option to CHANGE
MASTER. But as part of this worklog, the format of the realy-log.info file was
changed. The new format is not understood by earlier versions, and nor by
MariaDB 10.0, so changing server to those versions would cause the slave to
abort with an error due to reading incorrect data out of relay-log.info.

Fix this by backporting from the WL#344 patch just the code that understands
the new relay-log.info format. We still write out the old format, and none of
the MASTER_DELAY feature is backported with this commit.

Stop spawning dummy threads on client library initialization

Let's revert the fix for Bug#24507.  To quote Monty from 2006:

"After 1/2 a year, when all glibc versions are updated, we can delete
this code."

Note: The upstream glibc bug was fixed in 2006.

Preserve CLIENT_REMEMBER_OPTIONS flag for compressed connections

Code cleanup: removed reference to CLIENT_REMEMBER_OPTIONS from server
code. This flag is ignored in MariaDB.

The INCIDENT_EVENT always caused slave error and abort, without checking
--slave-skip-errors.

Now, if error 1590, ER_SLAVE_INCIDENT is included in the --slave-skip-errors
list, incident events will be ignored.

This is a merge of this MySQL 5.6 patch:

revision-id: frazer@mysql.com-20110314170916-ypgin17otj3ucx95
committer: Frazer Clement <frazer@mysql.com>
timestamp: Mon 2011-03-14 17:09:16 +0000
message:
  Bug#11799671 NOT POSSIBLE TO SKIP INCIDENT ERRORS

Use single quotes for perl paths, in case of special symbols

Double-quoted string literals are subject to backslash and variable
substitution.

Fixed some compilation errors/warnings with ASan.

  Some variables weren't cleared properly so consequitive embedded server start/stop failed.
  Cleanups added. Also mysql_client_test.c extended to test that (taken from Mattias Johnson's patch)

When plugin=mysql_native_password (or mysql_old_password) take the password
from *either* password *or* authentication_string, whichever is set.
This makes no sense, but alas, that's what MySQL-5.6 does.

fix for ranges like "indexed_datetime OP time"
(test case is in the previous revision)

fix for ref like "indexed_time = datetime"

(prep for MDEV-6065)