- errno handling in wsp::env::append() method, where error could be returned by mistake
  - return code of sst_prepare_other() when pthread_create() fails - it was returning positive error code which by convention is treated as success.

Synced xtrabackup SST fixes from Percona tree (as of PXC 5.6.24-25.11 release). This fixes/adresses the following LP bugs:
  - LP1380697: wsrep_sst_xtrabackup-v2 doesn't stop when mysql is SIGKILLed. (full fix for this (as engineeered by Percona) requires Linux-specific patch that we don't carry, but keep xtrabackup scripts as close as possible)
  - LP1399134: Log the innobackupex/SST logs in SST to syslog if possible. (fixed)
  - LP1405668: Race condition between donor and joiner in PXB SST. (fixed)
  - LP1405985: Fail early if xtrabackup_checkkpoints is missing. (fixed)
  - LP1407599: wsrep_sst_xtrabackup-v2 script causes innobackupex to print a false positive stack trace into the log. (fixed)
  - LP1441762: IST Fails with SST script error. (fixed)
  - LP1451670: Fail when move-back fails in xtrabackup SST. (fixed)

  1. Passes wsrep_sst_auth_value to SST scripts via WSREP_SST_OPT_AUTH envronmental variable, so it never appears on the command line
  2. In mysqldump and xtrabackup* SST scripts which rely on MySQL authentication, instead of passing password on the command line, SST script sets MYSQL_PWD environment variable, so that password also never appears on the mysqldump/innobackupex command line.

Do not replicate commands from check-warnings.test to other
nodes in the cluster.

When wsrep is enabled, for any update on innodb tables, the
corresponding keys are appended to galera's transaction writeset
(wsrep_append_keys()). However, for LOAD DATA, this got skipped
if binary logging was disabled or it was non-ROW based.
As a result, while the updates from LOAD DATA on non-partitioned
tables replicated fine as wsrep implicitly enables binary logging
(if not enabled, explicitly), the same did not work on partitioned
tables as for partitioned tables the binary logging gets disabled
temporarily (ha_partition::write_row()).

Fixed by removing the unwanted conditions from the check.
Also backported some changes from 10.0-galera to make sure
wsrep_load_data_splitting affects LOAD DATA commands only.

In galera cluster, when myisam replication is enabled
(wsrep_replicate_myisam=ON), DML statements are replicated
in open_tables(). However, in case of prepared statements,
for an INSERT, open_tables() gets invoked twice. Once for
COM_STMT_PREPARE (to validate and prepare INSERT) and later
for COM_STMT_EXECUTE. As a result, the command gets replicated
twice. Same happens for REPLACE, UPDATE and DELETE commands.
Fixed by adding a check to not replicate during 'prepare'
phase. Also changed the order of conditions to make it more
efficient. Lastly, in order to support wsrep_dirty_reads, made
changes to allow COM_STMT_XXX commands to continue past initial
check even when wsrep is not ready.

RENAME TABLE, unlike other DDLs, was getting replicated before
the access check was performed. As a result, the command could
get get replicated and thus executed on other nodes, even if it
fails on the originating node due to permission issues. Fixed by
moving the logic to check user privileges before replicating the
command.

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.

5.5.44-37.3

Correct fix for this bug.

The problem was that Item_func_group_concat() was calling
setup_order(), passing args as the second argument,
ref_pointer_array. While ref_pointer_array should have free
space at the end, as setup_order() can append elements to it.

In this particular case args[] elements were overwritten when
setup_order() was pushing new elements into ref_pointer_array.

Cherry-pick from 10.0:

  commit 126523d1
  Author: Sergei Golubchik <serg@mariadb.org>
  Date:   Mon Feb 23 20:53:41 2015 +0100

  MDEV-6703 Add "mysqlbinlog --binlog-row-event-max-size" support

Alternative fix that doesn't cause view.test crash in --ps:
Remember when Item_ref was fixed right in the constructor
and did not have a full Item_ref::fix_fields() call. Later
in PS/SP, after Item_ref::cleanup, we use this knowledge
to avoid doing full fix_fields() for items that were never
supposed to be fix_field'ed.

Simplify the test case.

Let mysql_upgrade return zero exit status when installation is up to date.

            execution of PS

GROUP_CONCAT() with ORDER BY column position may crash server on PS reexecution.

The problem was that arguments array of GROUP_CONCAT() was adjusted to point to
temporary elements (resolved ORDER BY fields) during first execution.

This patch expands rev. 08763096 to restore original arguments array as well.

There is several different ways to incorrectly define
foreign key constraint. In many cases earlier MariaDB
versions the error messages produced by these cases
are not very clear and helpful. This patch improves
the warning messages produced by foreign key parsing.

Added better error message that will be printed when foreign key
constraint name in create table is not unique in database.

GET_LOCK() silently accepted negative values and NULL for timeout.
Fixed GET_LOCK() to issue a warning and return NULL in such cases.

Fixed memory loss detected on P8. This can happen when we call after_flush but never call after_rollback() or after_commit().

The old code used pthread_setspecific() to store temporary data used by the thread.
This is not safe when used with thread pool, as the thread may change for the transaction.

The fix is to save the data in THD, which is guaranteed to be properly freed.
I also fixed the code so that we don't do a malloc() for every transaction.

field.cc
- Fixed warning about overlapping memory copy (backport from 10.0)

Item_subselect.cc
- Fixed core dump in main.view
- Problem was that thd->lex->current_select->master_unit()->item was not set, which caused crash in maxr_as_dependent

sql/mysqld.cc
- Got error on shutdown as we where freeing mutex before all THD objects was freed
  (~THD uses some mutex). Fixed by during shutdown freeing THD inside mutex.

sql/log.cc
- log_space_lock and LOCK_log where locked in inconsistenly. Fixed by not having a log_space_lock around purge_logs.

sql/slave.cc
- Remove unnecessary log_space_lock
- Move cond_broadcast inside lock to ensure we don't miss the signal

Analysis: At check_trx_exists function InnoDB allocates
a new trx if no trx is found from thd but this newly
allocated trx is not registered to thd. This is unsafe,
because nothing prevents InnoDB plugin from being uninstalled
while there's active transaction. This can cause crashes, hang
and any other odd behavior. It may also corrupt stack, as
functions pointers are not available after dlclose.

Fix: The fix is to use thd_set_ha_data() when
manipulating per-connection handler data. It does appropriate
plugin locking.

In galera, like other DDLs, CREATE/ALTER VIEW commands are recreated
and replicated during parsing. The ALGORITHM clause is internally set
to VIEW_ALGORITHM_INHERIT if its not explicitly specified by the user.
But since its not a valid type to be used in a command, it leads to an
assertion failure. The solution is to not include the ALGORITHM clause
in the command if its not explicitly specified (or INHERIT).

The fix is that if the slave has a different integer size than
the master, then they will assume the master has the same signed/unsigned modifier
as the slave.

This means that one can safely change a coon the slave an int to a bigint
or an unsigned int to an unsigned int.  Changing an unsigned int to an
signed bigint will cause replication failures when the high bit of the
unsigned int is set.

We can't give an error if the signess is different on the master and slave
as the binary log doesn't contain the signess of the column on the master.