Other things:
- Added DBUG_EXECUTE_IF("print_allocated_thread_memory") at end of query
  to easier find not freed memory allocated by THD
- Removed free_root() from plugin_init() that did nothing.

The problem was that table->vcol_cleanup_expr() was not called in case
of error in open_table().

The leaks are all 40 bytes and happens in this call stack when running
mtr vcol.vcol_syntax:

alloc_root()
...
Virtual_column_info::fix_and_check_exp()
...
Delayed_insert::get_local_table()

The problem was that one copied a MEM_ROOT from THD to a TABLE without
taking into account that new blocks would be allocated through the
TABLE memroot (and would thus be leaked).
In general, one should NEVER copy MEM_ROOT from one object to another
without clearing the copied memroot!

Fixed by, at end of get_local_table(), copy all new allocated objects
to client_thd->mem_root.

Other things:
- Removed references to MEM_ROOT::total_alloc that was wrongly left
  after a previous commit

This will enable safemalloc to resolve symbols when compiled with
__PIE__

The reason for this change are the following:
- If we call set_killed() from one thread to kill another thread with
  a message, there may be concurrent usage of the MEM_ROOT which is
  not supported (this could cause memory corruption).
  We do not currently have code that does this, but the API allows this
  and it is better to be fix the issue before it happens.
- The per thread memory tracking does not work if one thread uses
  another threads MEM_ROOT.
- set_killed() can be called if a MEM_ROOT allocation fails.  In this case
  it is not good to try to allocate more memory from potentially the same
  MEM_ROOT.

Fix is to use my_malloc() instead of mem_root for killed messages.

The stack function trace for this bug is:

libc
my_free
free_root
acl_reload

The crash happens because acl_memroot gets corrupted.

The issue was that during FLUSH PRIVILEGES we discard the old
privileges and create new ones. We have protection in place that no
one can accesses the privileges during this time.

However one short piece of code called during login of a new user, or
change password, was not properly protected, which could in some very
rare circumstances case a memory overwrite of a MEMROOT object if
at the same time another thread calls FLUSH PRIVILEGES.

This it issue is fixed by adding protection around set_user_salt().
I also added asserts to other code that is using the acl_memroot to
ensure that it is properly proteced everywhere.

- Record unrecorded tests from `rpl` suite to `engines/funcs` suite
(done by d8e448ba):
  1) Record test `rpl_row_until` from commit d95fa7e3
  2) Record test `rpl_slave_status` from commit a7d186a1

- Stop only running threads for `engines/funcs.rpl_server_id1.test` that
is not the same as `rpl.rpl_server_id1.test`

- Reviewer:  <knielsen@knielsen-hq.org>
             <andrei.elkin@mariadb.com>

mysql_prepare_alter_table(): Alter table should check whether
foreign key exists when it expected to exists and
report the error in early stage

dict_foreign_parse_drop_constraints(): Don't throw error if the
foreign key constraints doesn't exist when if exists is given
in the statement.

move MYSQL::fields down, replacing MYSQL::unused5

this way only MYSQL::fields and MYSQL::field_alloc will still have
different offset in C/C and the server, but all other MYSQL members
will get back in sync.

luckily, plugins shouldn't need MYSQL::fields or MYSQL::field_alloc

added a check to ensure both MYSQL structures are always of
the same size.

to fix sizeof(MEM_ROOT)

wait a bit more thoroughly for event scheduler to be fully started

followup for a7d186a1

After successful connection, server always sets SERVER_STATUS_AUTOCOMMIT
in server_status in the OK packet. This is wrong, if global variable
autocommit=0.

Fixed THD::init(), added mysql_client_test test.

Thanks to Diego Dupin for the providing the patch.
Signed-off-by: Vladislav Vaintroub <vvaintroub@gmail.com>

This bug was caused by a patch for the task MDEV-32733.
Incorrect memory root was used for allocation of memory
pointed by the data memebr Item_func_json_contains_path::p_found.

Let us make the test compatible with ./mtr --repeat
and convert variable_value to integer, so that comparisons like
16>9 will work as intended, instead of being compared as '16'<'9'.

MDEV-29070 SIGSEGV in my_decimal::operator= and Assertion `0' failed and in Item_type_holder::val_decimal on SELECT

The bug is fixed by the patch ported from MySQL. See the comprehensive
description below.

commit 455c4e8810c76430719b1a08a63ca0f69f44678a
Author: Guilhem Bichot <guilhem.bichot@oracle.com>
Date:   Fri Mar 13 17:51:27 2015 +0100

    Bug#17668844: CRASH/ASSERT AT ITEM_TYPE_HOLDER::VAL_STR IN ITEM.C

    We have a predicate of the form:
    literal_row <=> (a UNION)

    The subquery is constant, so Item_cache objects are used for its
    SELECT list.
    In order, this happens:
    - Item_subselect::fix_fields() calls select_lex_unit::prepare,
    where we create Item_type_holder's
    (appended to unit->types list), create the tmp table (using type info
    found in unit->types), and call fill_item_list() to put the
    Item_field's of this table into unit->item_list.
    - Item_subselect::fix_length_and_dec() calls set_row() which
    makes Item_cache's of the subquery wrap the Item_type_holder's
    - When/if a first result row is found for the subquery,
    Item_cache's are re-pointed to unit->item_list
    (i.e. Item_field objects which reference the UNION's tmp table
    columns) (see call to Item_singlerow_subselect::store()).
    - In our subquery, no result row is found, so the Item_cache's
    still wrap Item_type_holder's; evaluating '<=>' reads the
    value of those, but Item_type_holder objects are not expected to be
    evaluated.

    Fix: instead of putting unit->types into Item_cache, and later
    replacing with unit->item_list, put unit->item_list in Item_cache from
    the start.

Approved by Oleksandr Byelkin <sanja@mariadb.com>

This is the follow-up patch that removes explicit use of thd->stmt_arena
for memory allocation and replaces it with call of the method
  THD::active_stmt_arena_to_use()
Additionally, this patch adds extra DBUG_ASSERT to check that right
query arena is in use.

This patch is actually follow-up for the task
  MDEV-23902: MariaDB crash on calling function
to use correct query arena for a statement. In case invocation of
a function is in progress use its call arena, else use current
query arena that can be either a statement or a regular query arena.

We remove the call to update spider persistent table stats (sts/crd)
in spider_free_share(). This prevents spider from opening and closing
further tables during close(), which fixes the following issues:

MDEV-28739: ha_spider::close() is called during tdc_start_shutdown(),
which is called after query_cache_destroy(). Closing the sts/crd Aria
tables will trigger a call to Query_cache::invalidate_table(), which
will attempt to use the query cache mutex structure_guard_mutex
destroyed previously.

MDEV-29421: during ha_spider::close(), spider_free_share() could
trigger another spider_free_share() through updating sts/crd table,
because open_table() calls tc_add_table(), which could trigger another
ha_spider::close()...

Since spider sts/crd system tables are only updated here, there's no
use for these tables any more, and we remove all uses of these tables
too.

The removal should not cause any performance issue, as in memory
spider table stats are only updated based on a time
interval (spider_sts_interval and spider_crd_interval), which defaults
to 10 seconds. It should not affect accuracy either, due to the
infrequency of server restart. And inaccurate stats are not a problem
for optimizer anyway.

To be on the safe side, we defer the removal of the spider sts/crd
tables themselves to future.

They are not used. The code paths are never reached.

This could help prevent race condition when shutting down the server
not long after loading spider. Thus only needed for 10.4-10.6.

btr_cur_update_in_place(): Update the DB_TRX_ID,DB_ROLL_PTR also on the
compressed copy of the page. In a test case, a server built with
cmake -DWITH_INNODB_EXTRA_DEBUG=ON would crash in page_zip_validate()
due to the inconsistency. In a normal debug build, a different assertion
would fail, depending on when the uncompressed page was restored from
the compressed page.

In MariaDB Server 10.5, this bug had already been fixed by
commit b3d02a1f (MDEV-12353).

sets of the first and second execution. The results of the first
and second execution are compared only if result logging is enabled
Comparing two result sets is done as comparing two strings.

Added a new method 'read_stmt_results' to get a result set
after execution of prepare statement.

- Allow database level access via `LOCK TABLES` to execute statement
`BACKUP [un]LOCK <object>`
- `BACKUP UNLOCK` works only with `RELOAD` privilege.
  In case there is `LOCK TABLES` privilege without `RELOAD` privilege,
  we check if backup lock is taken before.
  If it is not we raise an error of missing `RELOAD` privilege.
- We had to remove any error/warnings from calling functions because
`thd->get_stmt_da()->m_status` will be set to error and will break
`my_ok()`.
- Added missing test coverage of `RELOAD` privilege to `main.grant.test`
Reviewer: <daniel@mariadb.org>

Statements affected by this bug have all the following
1) select statements with a sub-query
2) that sub-query includes a group-by clause
3) that group-by clause contains an expression
4) that expression has a reference to view

When a view is used in a group by expression, and that group by can be
eliminated in a sub-query simplification as part of and outer condition
that could be in, exists, > or <, then the table structure left behind
will have a unit that contains a null select_lex pointer.

If this happens as part of a prepared statement, or execute in a stored
procedure for the second time, then, when the statement is executed, the table
list entry for that, now eliminated, view is "opened" and "reinit"ialized.
This table entry's unit no longer has a select_lex pointer.
Prior to MDEV-31995 this was of little consequence, but now following this
null pointer will cause a crash.

Reviewed by Igor Babaev (igor@mariadb.com)

- Add selected tables as shared keys for CTAS certification
- Set proper security context on the replayer thread
- Disallow CTAS command retry
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

This is caused by fact that VARIABLE_VALUE is defined in
variables_fields_info (sql_show.cc) as 2048.
wsrep_provider_options contain few path variables and
this could cause string truncation on deep and long
directory paths.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

Problem:
========
- InnoDB fails to free the allocated buffer of stored cursor
when information schema query is interrupted.

Solution:
=========
- In case of error handling, information schema query should free
the allocated buffer to store the cursor.

It is unused, and causing segfaults

Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

- Commit e3bffd57 introduced the change
- Fixed with commit 2d857144 in 10.4 (no removal of
`Wimplicit-fallthrough=2`)
- Fixed with commit 4a75b480 in 10.5+

- Closing PR #2817
Reviewed by: <monty@mariadb.org>

This will avoid issues like MDEV-32486

IDs used in
- spider_alloc_calc_mem_init()
- spider_string::init_calc_mem()
- spider_malloc()
- spider_bulk_alloc_mem()
- spider_bulk_malloc()

The server doesn't use the enforced storage engine in ALTER TABLE
without ENGINE clause to avoid an unwanted engine change.

However, the server tries to use the enforced engine in CREATE
INDEX. As a result, the false positive error is raised. The server
should not apply the enforced engine in CREATE INDEX too.