Item_func_sysconst behaves as a non-constant function during prepared
statements and view creation and constant otherwise. Current condition
implied the opposite.

MDEV-10880: Assertions `keypart_map' or `prebuilt->search_tuple->n_fields > 0' fail on DISTINCT and GROUP BY constant

add_group_and_distinct_keys() should take into account JOIN::simple_group.

prepare of "fake_select" for union made in JOIN::prepare only if
we do not execute it then before reset, i.e it was for PS prepare
and now required for CREATE VIEW to make global ORDER BY which
belongs to "fake_select" prepared.

https://github.com/percona/percona-xtrabackup/pull/368/commits/72c55f4fc2ba9ede7b960eceb01261ccc339c041

fix a merge mistake

MyISAM only allows online alter if autoincrement didn't change.
MyISAM detects that by comparing new autoinc value from create_info,
with the old one, stored in MYI. But in partitioned tables,
create_info->auto_increment_value is for the whole table, max of
autoinc values of individual MYI partitions. So *some* MYI partitions
will inevitably think that alter table changes auto_increment value
and will deny online alter.

Fix: only compare autoinc values, if the user has used AUTO_INCREMENT
in the ALTER TABLE statement.

MDEV-13012 Assertion `share->error' failed in discover_handlerton upon executing statement with max_session_mem_used = 8192

and
MDEV-13011 Server crashes in THD::handle_condition or Assertion `! is_set() || m_can_overwrite_status' fails upon attempt to connect with max_session_mem_used = 8192

errors when a connection is killed in the
* TABLE_SHARE::init_from_sql_statement_string()
* THD::init()

also, safety-wise, don't check max_mem_used on free() and when some error
was already issued.

it was disabled in mtr tests in 4280b25e

Comment from Codership:-
To fix the problem, we changed the certification logic in galera to treat insert
on child table row as exclusive to prevent any operation on referenced
parent table row. At the same time, update and delete on
 child table row were demoted to "shared", which makes it possible to
update/delete referenced parent table row, but only in a later transaction.
 This change allows somewhat more concurrency for foreign key constrained
 transactions, but is still safe for correct certification end result.

using "show variables", rather than take the value from my.cnf.

"show variables" is more accurate than my.cnf,it also works for parameters
set on the mysqld command line, which is especially important for MTR.

MDEV-12975 InnoDB redo log minimum size check uses detected file size instead of requested innodb_log_file_size

log_calc_max_ages(): Use the requested size in the check, instead of
the detected redo log size. The redo log will be resized at startup
if it differs from what has been requested.

MDEV-12975 InnoDB redo log minimum size check uses detected file size instead of requested innodb_log_file_size

log_calc_max_ages(): Use the requested size in the check, instead of
the detected redo log size. The redo log will be resized at startup
if it differs from what has been requested.

The bug happens because of a combination of unfortunate circumstances:

1. Arguments args[0] and args[2] of Item_func_concat point recursively
(through Item_direct_view_ref's) to the same Item_func_conv_charset.
Both args[0]->args[0]->ref[0] and args[2]->args[0]->ref[0] refer to
this Item_func_conv_charset.

2. When Item_func_concat::args[0]->val_str() is called,
Item_func_conv_charset::val_str() writes its result to
Item_func_conc_charset::tmp_value.

3. Then, for optimization purposes (to avoid copying),
Item_func_substr::val_str() initializes Item_func_substr::tmp_value
to point to the buffer fragment owned by Item_func_conv_charset::tmp_value
Item_func_substr::tmp_value is returned as a result of
Item_func_concat::args[0]->val_str().

4. Due to optimization to avoid memory reallocs,
Item_func_concat::val_str() remembers the result of args[0]->val_str()
in "res" and further uses "res" to collect the return value.

5. When Item_func_concat::args[2]->val_str() is called,
Item_func_conv_charset::tmp_value gets overwritten (see #1),
which effectively overwrites args[0]'s Item_func_substr::tmp_value (see #3),
which effectively overwrites "res" (see #4).

This patch does the following:

a. Changes Item_func_conv_charset::val_str(String *str) to use
   tmp_value and str the other way around. After this change tmp_value
   is used to store a temporary result, while str is used to return the value.
   The fixes the second problem (without SUBSTR):
     SELECT CONCAT(t2,'-',t2) c2
       FROM (SELECT CONVERT(t USING latin1) t2 FROM t1) sub;
   As Item_func_concat::val_str() supplies two different buffers when calling
   args[0]->val_str() and args[2]->val_str(), in the new reduction the result
   created during args[0]->val_str() does not get overwritten by
   args[2]->val_str().

b. Fixing the same problem in val_str() for similar classes

   Item_func_to_base64
   Item_func_from_base64
   Item_func_weight_string
   Item_func_hex
   Item_func_unhex
   Item_func_quote
   Item_func_compress
   Item_func_uncompress
   Item_func_des_encrypt
   Item_func_des_decrypt
   Item_func_conv_charset
   Item_func_reverse
   Item_func_soundex
   Item_func_aes_encrypt
   Item_func_aes_decrypt
   Item_func_buffer

c. Fixing Item_func::val_str_from_val_str_ascii() the same way.
   Now Item_str_ascii_func::ascii_buff is used for temporary value,
   while the parameter passed to val_str() is used to return the result.
   This fixes the same problem when conversion (from ASCII to e.g. UCS2)
   takes place. See the ctype_ucs.test for example queries that returned
   wrong results before the fix.

d. Some Item_func descendand classes had temporary String buffers
   (tmp_value and tmp_str), but did not really use them.
   Removing these temporary buffers from:

   Item_func_decode_histogram
   Item_func_format
   Item_func_binlog_gtid_pos
   Item_func_spatial_collection:

e. Removing Item_func_buffer::tmp_value, because it's not used any more.

f. Renaming Item_func_[un]compress::buffer to "tmp_value",
   for consistency with other classes.

Note, this patch does not fix the following classes
(although they have a similar problem):

   Item_str_conv
   Item_func_make_set
   Item_char_typecast

They have a complex implementations and simple swapping between "tmp_value"
and "str" won't work. These classes will be fixed separately.

The option was basically duplicating InnoDB functionality.
Persistent statistics can be accessed via the tables
mysql.innodb_table_stats and mysql.innodb_index_stats.

These functions cannot possibly work in MariaDB 10.2, and it is
uncertain if they really work in 10.1 either.

This has been implemented in for cmake-3.6 to match distro version
of what the filename should look like.

Thanks to Domen Vranka for the suggestion.

regex didn't replace lines that were split by 16K chunk reads.

             lock not released after timeout

Release GRL if FLUSH TABLES phase failed.

The problem lies in how CURRENT_ROLE is defined. The
Item_func_current_role inherits from Item_func_sysconst, which defines
a safe_charset_converter to be a const_charset_converter.

During view creation, if there is no role previously set, the current_role()
function returns NULL.

This is captured on item instantiation and the
const_charset_converter call subsequently returns an Item_null.
In turn, the function is replaced with Item_null and the view is
then created with an Item_null instead of Item_func_current_role.

Without this patch, the first SHOW CREATE VIEW from the testcase would
have a where clause of WHERE role_name = NULL, while the second SHOW
CREATE VIEW would show a correctly created view.

The same applies for the DATABASE function, as it can change as well.

There is an additional problem with CURRENT_ROLE() when used in a
prepared statement. During prepared statement creation we used to set
the string_value of the function to the current role as well as the
null_value flag. During execution, if CURRENT_ROLE was not null, the
null_value flag was never set to not-null during fix_fields.

Item_func_current_user however can never be NULL so it did not show this
problem in a view before. At the same time, the CURRENT_USER() can not
be changed between prepared statement execution and creation so the
implementation where the value is stored during fix_fields is
sufficient.

Note also that DATABASE() function behaves differently during prepared
statements. See bug 25843 for details or commit
7e0ad09e

The problem lies in not checking role privileges as well during SHOW
DATABASES command. This problem is also apparent for SHOW CREATE
DATABASE command.

Other SHOW COMMANDS make use of check_access, which in turn makes use of
acl_get for both priv_user and priv_role parts, which allows them to
function correctly.

dict_table_t::thd: Remove. This was only used by btr_root_block_get()
for reporting decryption failures, and it was only assigned by
ha_innobase::open(), and never cleared. This could mean that if a
connection is closed, the pointer would become stale, and the server
could crash while trying to report the error. It could also mean
that an error is being reported to the wrong client. It is better
to use current_thd in this case, even though it could mean that if
the code is invoked from an InnoDB background operation, there would
be no connection to which to send the error message.

Remove dict_table_t::crypt_data and dict_table_t::page_0_read.
These fields were never read.

fil_open_single_table_tablespace(): Remove the parameter "table".

MDEV-13063 Server crashes in intern_plugin_lock or assertion `plugin_ptr->ref_count == 1' fails in plugin_init

if a forced plugin is disabled (for any reason, e.g. invalid command-line
option) - it's an error

Cover innodb.table_flags with the new innodb_page_size.combinations
32k and 64k.

dict_sys_tables_type_validate(): Remove an assertion that made a
check in the function redundant. Remove the excessive output to
the error log, as the invalid SYS_TABLES.TYPE value is already being
output.