This bug is essentially another variant of MDEV-7458.

If a transaction conflict caused a deadlock kill of T2 in record_gtid()
during commit, the code would do a rollback _before_ running
rgi->unmark_start_commit(). This creates a race where following transactions
could start too early (before T2 has completed its transaction retry). This
in turn could lead to replication failure, if there was a conflict that
caused eg. duplicate key error or similar.

The fix is to remove these rollbacks (in Query_log_event::do_apply_event()
and Xid_log_event::do_apply_event(). They seem out-of-place; code in
log_event.cc generally does not roll back on error, this is handled higher
up.

In addition, because of the extreme difficulty of reproducing bugs like
MDEV-7458 and MDEV-8302, this patch adds some extra precations to try to
detect (in debug builds) or prevent (in release builds) similar bugs.
ha_rollback_trans() will now call unmark_start_commit() if needed (and
assert in debug build when a caller does rollback without unmark first).

We also add an extra check for thd->killed() so that we avoid doing
mark_start_commit() if we already have a pending deadlock kill.

And we add a missing unmark_start_commit() call in the error case, found by
the above assertion.

The problem was with Materialized_cursor and temporary table it uses.
Temorary table's fields had Field::orig_table pointing to the tables
that were used in the query that produced data for the cursor.
When "FETCH INTO sp_var" statement is executed, those original tables
were already closed.  However, copying from Materialized_cursor's table
into SP variable may cause field_conv() to be invoked which calls
field->type() which may access field->orig_table (for certain field types).

Fixed by setting Materialized_cursor->table->field[i]->orig_table to point
to Materialized_cursor->table.  (this is how it is done for regular base
tables)

THD::>save_prep_leaf_list was set to true by multi-table update
statements with mergeable selects and never reset.

Make every statement reset it at start.

[Attempt #] Make the code that handles "Prepare" phase for multi-table
UPDATE statements handle non-merged semijoins. It can encounter them when
a prepared statement is executed for the second time.

            with plugin-load-add that are already registered at mysql.plugin

- issue just one error message, without this extra warning
- don't abuse ER_UDF_EXISTS, instead add a proper error message for plugins
- report started initialization for each plugin source

Don't forget to set thd->lex->unit.insert_table_with_stored_vcol
in the mysql_load(). Othewise virtual columns will not be updated.

and don't check table privileges in external_lock(F_UNLCK).

(patch originally by Alexander Barkov)

Instead of checking user's privileges with check_access(),
use the cached value in table->grant.privilege instead -
it is correctly set to the invoker or definer, depending
on SQL SECURITY mode.

Continue to use check_access() for DDLs when
table->grant.privilege may be not set (but these cases are
only possible on tables, never for views).

(patch originally by Alexander Barkov)

prevent concurrent cleanups in multi-threaded mysqlimport
(they can happen if many threads get an error at the same time),
safe_exit() is not thread-safe.

fix the previous patch to pass defaults-file to parse_arguments

backport https://github.com/MariaDB/server/pull/88 to 10.0

Added some extra safety asserts in MyISAM key cache.

my_thread_var->init is now:
0 at startup
1 at init
2 when thread dies

Fix was to add a test in Query_log_event::Query_log_event() if we are using
CREATE ... SELECT and in this case use trans cache, like we do on the master.
This avoid using (with doesn't have checksum)

Other things:
- Removed dummy call my_checksum(0L, NULL, 0)
- More DBUG_PRINT
- Cleaned up Log_event::need_checksum() to make it more readable (similar as in MySQL 5.6)
- Renamed variable that was hiding another one in create_table_imp()

Do not attempt to run unix-specific code on Windows

FUNCTIONS/PRIVILEGES DIFFERENTLY'

Fix for bug#11759114 - '51401: GRANT TREATS NONEXISTENT
FUNCTIONS/PRIVILEGES DIFFERENTLY'.

The problem was that attempt to grant EXECUTE or ALTER
ROUTINE privilege on stored procedure which didn't exist
succeed instead of returning an appropriate error like
it happens in similar situation for stored functions or
tables.

The code which handles granting of privileges on individual
routine calls sp_exist_routines() function to check if routine
exists and assumes that the 3rd parameter of the latter
specifies whether it should check for existence of stored
procedure or function. In practice, this parameter had
completely different meaning and, as result, this check was
not done properly for stored procedures.

This fix addresses this problem by bringing sp_exist_routines()
signature and code in line with expectation of its caller.
Conflicts:
	mysql-test/r/grant.result
	mysql-test/t/grant.test
	sql/sp.cc

- since param is quite small store it on stack
- fixed a few memory leaks

 "mtr connect.odbc_postgresql"

The test has performance-schema in the opt file, so it failed when the server was compiled without performance schema.
Make the option loose, then MTR will be able to reach have_perfschema.inc check and will skip the test gracefully.

Problem was that test just takes too long time in slow I/O and triggers
testcase timeout. Reduced the number of operations and inserts to make
test shorter.

--gtid-ignore-duplicates was comparing sequence numbers as 32-bit, so
after 2**32 transactions things would start to fail.

Let mysqld_safe_syslog.cnf force disable error log so that logging to syslog is
not affected by previous log_error setting.

Added handling of --skip-log-error to mysqld_safe.

Merge error on srv0start.cc

Fixed small size limit and added additional information if we reserve
new pages more then 50 times.

Apply fixes for raw devices to XtraDB in MariaDB 10.0

- References changed from mysql.com to mariadb.com/kb
- NDB specfic things removed
- Changed other MySQL related things to MariaDB

Analysis; Problem is that InnoDB does not have support for generating
CURRENT_TIMESTAMP or constant default.

Fix: Add additional check if column has changed from NULL -> NOT NULL
and column default has changed. If this is is first column definition
whose SQL type is TIMESTAMP and it is defined as NOT NULL and
it has either constant default or function default we must use
"Copy" method for alter table.

The --gtid-ignore-duplicates option was not working correctly with row-based
replication. When a row event was completed, but before committing, there
was a small window where another multi-source SQL thread could wrongly try
to re-execute the same transaction, without properly ignoring the duplicate
GTID. This would lead to duplicate key error or out-of-order GTID error or
similar.

Thanks to Matt Neth for reporting this and giving an easy way to reproduce
the issue.

fix the test case for ps-protocol

MDEV-5977 MariaDB 10.0 is not installable on Trusty when "trusty-updates universe" is in sources.list

fix upgrade[2] tests on trusty and utopic: add missing
conflicts/replaces, client-10.0 should conflict/replace client-5.5.

reformat other conflicts/replaces lines to make them easier
to read and merge