Statements affected by this bug are delete statements that have all
these conditions

1) single table delete syntax
2) and in (sub-query) predicate
3) semi-join optimization enabled
4) an order by clause.

Semijoin optimization on an innocent looking query, such as

DELETE FROM t1 WHERE c1 IN (select c2 from t2) ORDER BY c1;

turns it from a single table delete to a multi-table delete.

During multi_delete::initialize_tables for the top level join object, a
table is initialized missing a keep_current_rowid flag, needed to
position a handler for removal of the correct row after the filesort
structure has been built.

Fix provided by Monty (monty@mariadb.com)
Pushed into 10.5 at Monty's request.
Applicable to 10.6, 10.11, 11.0.
OK'd by Monty in slack:#askmonty 2023-12-01

followup for 5bb31bc8

mtr_t::commit(): If IMPORT TABLESPACE is first-time-dirtying blocks,
acquire both log_sys.mutex and log_sys.flush_order_mutex to assign
a valid m_commit_lsn so that the block will be inserted into the
correct position of buf_pool.flush_list.

This fixes occasional debug assertion failures when running the
regression test suite.

Reviewed by: Vladislav Lesin

Using mysql.slow_log was a test table would generate more than
one row if there was more than one row in the table.

Replace this table with a empty table with PK.

Reviewer: Rex Johnston

row_upd_clust_rec_by_insert(): If we are resuming from a lock wait,
reset the 'disowned' flag of the BLOB pointers in 'entry' that we
copied from 'rec' on which we had invoked btr_cur_disown_inherited_fields()
before the lock wait started. In this way, the inserted record with
the updated PRIMARY KEY value will have the BLOB ownership associated
with itself, like it is supposed to be.

Note: If the lock wait had been aborted, then rollback would have
invoked btr_cur_unmark_extern_fields() and no corruption would be possible.

Reviewed by: Vladislav Lesin
Tested by: Matthias Leich

ha_innobase::extra() invokes check_trx_exists() unconditionally even for
not supported operations. check_trx_exists() creates and registers trx_t
object if THD does not contain pointer to it. If ha_innobase::extra() does
not support some operation, it just invokes check_trx_exists() and quites.
If check_trx_exists() creates and registers new trx_t object for such
operation, it will never be freed and deregistered.

For example, if ha_innobase::extra() is invoked from purge thread with
operation = HA_EXTRA_IS_ATTACHED_CHILDREN, like it goes in
gcol.gcol_purge test, trx_t object will be registered, but not
deregisreted, and this causes innodb.gap_lock failure, as "SHOW ENGINE
INNODB STATUS" shows information about unexpected transaction at the end
of trx_sys.trx_list.

The fix is not to invoke check_trx_exists() for unsupported operations
in ha_innobase::extra().

Reviewed by: Marko Mäkelä

- Added the parameter stats_persistent=0 for InnoDB engine.
- Before printing metadata_lock_info query, make sure that
InnoDB does complete purging.

Reviewed by: Marko Mäkelä

trx_t::commit_in_memory(): Empty the detailed_error string, so that
FOREIGN KEY error messages from an earlier transaction will not be
wrongly reused in ha_innobase::get_error_message().

Reviewed by: Thirunarayanan Balathandayuthapani

It may be the case that for some reason, -Werror deprecated
for instance, that mallinfo isn't detected. In this case the
malloc.h headers won't be included which defined the mallinfo2
function and its structure.

Re-organise so that either function pulls in the header.

The problem is that background statistics can race with statistics update
during INSERT and cause slightly inaccurate `Rows` count in table statistics
(this is deliberate to avoid excessive locking overhead). This was seen as
occasional .result difference in the test.

Mask out the unstable `Rows` column from SHOW TABLE STATUS; the value is not
related to what is being tested in this part of the test case.

Run ANALYZE TABLE before SHOW EXPLAIN to get stable row count in output.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

Fix some random test failures following MDEV-32168 push.

Don't blindly set $rpl_only_running_threads in many places. Instead explicit
stop only the IO or SQL thread, as appropriate. Setting it interfered with
rpl_end.inc in some cases. Rather than clearing it afterwards, better to
not set it at all when it is not needed, removing ambiguity in the test
about the state of the replication threads.

Don't fail the test if include/stop_slave_io.inc finds an error in the IO
thread after stop. Such errors can be simply because slave stop happened in
the middle of the IO thread's initial communication with the master.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

--debug is supported by allmost all our other binaries and we should keep
it also in the server to keep option names similar.

debug_sync.h was wrongly combined with replication

This was a bug in my previous commit, found by buildbot

MDEV-29913 Assertion `thd->stmt_arena != thd->progress.arena' failed in thd_progress_init upon bulk load

- Commit fc31e311(MDEV-8179) doesn't
report the progress of inplace alter completely. It just does only
in row_merge_sort(). Removing the progress report function completely

MDEV-32890  LeakSanitizer errors in mem_heap_create_block_func upon query from I_S.INNODB_SYS_TABLES with LIMIT ROWS EXAMINED

- innodb_sys_tables query fails to free the object which contains
sys_tables information in case of error.

See: https://mariadb.org/mailing-lists/

MDEV-32879 Server crash in my_decimal::operator= or unexpected ER_DUP_ENTRY upon comparison with INET6 and similar types

During the 10.5->10.6 merge please use the 10.6 code on conflicts.

This is the 10.5 version of the patch (a backport of the 10.6 version).
Unlike 10.6 version, it makes changes in plugin/type_inet/sql_type_inet.*
rather than in sql/sql_type_fixedbin.h

Item_bool_rowready_func2, Item_func_between, Item_func_in
did not check if a not-NULL argument of an arbitrary data type
can produce a NULL value on conversion to INET6.

This caused a crash on DBUG_ASSERT() in conversion failures,
because the function returned SQL NULL for something that
has Item::maybe_null() equal to false.

Adding setting NULL-ability in such cases.

Details:

- Removing the code in Item_func::setup_args_and_comparator()
  performing character set aggregation with optional narrowing.
  This aggregation is done inside Arg_comparator::set_cmp_func_string().
  So this code was redundant

- Removing Item_func::setup_args_and_comparator() as it git simplified to
  just to two lines:
    convert_const_compared_to_int_field(thd);
    return cmp->set_cmp_func(thd, this, &args[0], &args[1], true);
  Using these lines directly in:
    - Item_bool_rowready_func2::fix_length_and_dec()
    - Item_func_nullif::fix_length_and_dec()

- Adding a new virtual method:
  - Type_handler::Item_bool_rowready_func2_fix_length_and_dec().

- Adding tests detecting if the data type conversion can return SQL NULL into
  the following methods of Type_handler_inet6:
  - Item_bool_rowready_func2_fix_length_and_dec
  - Item_func_between_fix_length_and_dec
  - Item_func_in_fix_comparator_compatible_types

This avoids the scenario in MDEV-32849, when the unlock happens after
the connection has been freed, say in rollback. This is done in 10.5+
after the commit a26700cc.

It may or may not prevent potential other scenarios where spider has
locked something, then for some reason the statement needs to be
rolled back and spider frees the connection, and then spider proceeds
to use the freed connection. But at least we fix the regression
introduced by MDEV-30014 to 10.4 and bring 10.4 closer in parity with
10.5+.

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.