maria:bb-10.6-MDEV-22718

Last commit made on 2022-09-19
Get this branch:
git clone -b bb-10.6-MDEV-22718 https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-10.6-MDEV-22718
Repository:
lp:maria

Recent commits

62de4ad... by Marko Mäkelä

WIP MDEV-22718: purge_sys.low_limit_no() is not protected

purge_sys_t::low_limit_no(): Adjust a comment. Actually, this
is protected after all.

TrxUndoRsegsIterator::set_next(): Reduce the critical section
of purge_sys.rseg->latch. Some purge_sys fields are accessed
only by the purge coordinator task.

5e270ca... by Daniel Black

MDEV-16708: ps_missed_cmds test - HELP deconflict

To make it possible to update the HELP text of UPDATE without
changing this test every time, the test is changed to look
for a faked help topic. A non-existant help topic generates
different metadata and wasn't suitable as a test.

Requested by Ian Gilfillan.

Reviewed by Dmitry Shulga

fd0bdd3... by Marko Mäkelä

Merge 10.5 into 10.6

0ccb95c... by Marko Mäkelä

Merge 10.5 into 10.6

fb70bb4... by Vladislav Vaintroub

MDEV-29513 avoid useless os_thread_sleep() during srv_purge_shutdown()

use waitable_task.wait() function to wait for the end of previous purge

bc12478... by Andrei <email address hidden>

MDEV-24660 MYSQL_BIN_LOG::cleanup(): Assertion `b->xid_count == 0'

The shutdown time assert was caused by untimely deactivation of
the binlog background thread and related structs destruction.
It could specifically occur when a transaction is replication unsafe
and has to be completed with a ROLLBACK event in binlog.

This gets fixed with the binlog background thread stop relocation
to a point and user transactions have been completed.
A test case is added to binlog.binlog_checkpoint which
also receives as a bonus a minor correction to reactivate a MDEV-4322 test
case that originally required a shutdown phase (that ceased to do).

7002173... by Nayuta Yanagisawa

MDEV-27172 fixup: spider/bugfix.mdev_27172 failed with --ps-protocol

d2e649a... by Marko Mäkelä

MDEV-29440 InnoDB instant ALTER TABLE recovery must use READ UNCOMMITTED

In commit 8f8ba758559e473f643baa0a0601d321c42517b9 (MDEV-27234)
the data dictionary recovery was changed to use READ COMMITTED
so that table-rebuild operations (OPTIMIZE TABLE, TRUNCATE TABLE,
some forms of ALTER TABLE) would be recovered correctly.

However, for operations that avoid a table rebuild thanks to
being able to instantly ADD, DROP or reorder columns, recovery
must use the READ UNCOMMITTED isolation level so that changes to
the hidden metadata record can be rolled back.

We will detect instant operations by detecting uncommitted changes
to SYS_COLUMNS in case there is no uncommitted change of SYS_TABLES.ID
for the table. In any table-rebuilding DDL operation, the SYS_TABLES.ID
(and likely also the table name) will be updated.

As part of rolling back the instant ALTER TABLE operation, after the
operation on the hidden metadata record has been rolled back, a rollback
of an INSERT into SYS_COLUMNS in row_undo_ins_remove_clust_rec() will
invoke trx_t::evict_table() to discard the READ UNCOMMITTED definition
of the table. After that, subsequent recovery steps will load and use
the correct table definition.

Reviewed by: Thirunarayanan Balathandayuthapani
Tested by: Matthias Leich

0fa4dd0... by Vlad Lesin

MDEV-29433 innodb.lock_delete_updated is unstable

Use suspend thread syncpoint instead of include/wait_condition.inc to
make sure DELETE created waiting lock before the next UPDATE begins
locking.

5563202... by Andrei <email address hidden>

MDEV-29322 ASAN heap-use-after-free in Query_log_event::do_apply_event

The ASAN report was made in the parallel slave execution of a query
event and implicitly involved (so also parallelly run) Format-Description
event.
The Query actually had unexpected impossible dependency on a preceding
"old" FD whose instance got destructed, to cause the ASAN error.

The case is fixed with storing the FD's value into Query-log-event
at its instantiating on slave. The stored value is from the very
FD of the Query's original binlog so remains to be correct
at the query event applying.

The branch C. of a new rpl_parallel_29322.test also demonstrates
(may need few --repeat though) the bug in its simple form of the same
server version binlog.