MariaDB

maria:bb-10.9-midenok-tmp

  1. Git
  2. lp:maria
  3. bb-10.9-midenok-tmp
Last commit made on 2022-07-07
Get this branch:
git clone -b bb-10.9-midenok-tmp https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-10.9-midenok-tmp
Repository:
lp:maria

Recent commits

a890e27... by midenok

Tmp

2b9fb34... by midenok

MDEV-28978 Assertion failure in THD::binlog_query or unexpected
    ER_ERROR_ON_WRITE with auto-partitioning

Added check whether binlogging is enabled before doing binlog_query().

f885116... by midenok

MDEV-28567 Assertion `0' in open_tables upon function-related operation

DBUG_ASSERT(0) was added by MDEV-17554 (auto-create history
partitions) as an experimental measure. Testing has shown this
conditional branch of can_recover_from_failed_open() can be possible
due to MDL deadlock.

The fix replaces DBUG_ASSERT with more specific one for
!OT_ADD_HISTORY_PARTITION.

Test case was synchronized to reproduce deadlock always and commented
with execution path of MDL locking for Good (no deadlock) and Bad
(deadlock). The logging was done with the help of preceding patch for
debug MDL tracing.

4a16436... by Marko Mäkelä

Merge 10.8 into 10.9

b283fd4... by Marko Mäkelä

Merge 10.7 into 10.8

cac6f0a... by Marko Mäkelä

Merge 10.6 into 10.7

c1e3fc0... by Marko Mäkelä

MDEV-28977: mariabackup.huge_lsn,strict_full_crc32 fails in 10.8

recv_sys_t::recover_deferred(): Hold the exclusive page latch until
the tablespace has been set up. Otherwise, the write of the page
may be lost due to non-existent tablespace. This race only affects
the recovery of the first page in a newly created tablespace.

This race condition was introduced in MDEV-24626.

2fa3ada... by Marko Mäkelä

Fix a sporadic failure of main.backup_locks

Ever since commit 9608773f75e2ca21491ef6825c3616cdc96d1ca5
the InnoDB persistent statistics are enabled on all InnoDB tables
by default. We must filter out any output that indicates that the
statistics tables are being internally accessed by InnoDB.

5e40934... by Monty <email address hidden>

MDEV-28897 Wrong table.get_ref_count() upon concurrent truncate and backup stage operation

The issue was that flush_tables() didn't take a MDL lock on cached
TABLE_SHARE before calling open_table() to do a HA_EXTRA_FLUSH call.
Most engines seams to have no issue with it, but apparantly this conflicts
with InnoDB in 10.6 when using TRUNCATE

Fixed by taking a MDL lock before trying to open the table in
flush_tables().

There is no test case as it hard to repeat the scheduling that causes
the error. I did run the test case in MDEV-28897 to verify
that the bug is fixed.

02a313d... by Marko Mäkelä

MDEV-18976 fixup: encryption.innodb-redo-nokeys

This test failure is similar to encryption.innodb-redo-badkey,
which was fixed in commit 0f0a45b2dc9fe3c54ca9d146db8068b50fc97138.