maria:bb-10.10-bar-MDEV-23287-inet4

Last commit made on 2022-07-08
Get this branch:
git clone -b bb-10.10-bar-MDEV-23287-inet4 https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-10.10-bar-MDEV-23287-inet4
Repository:
lp:maria

Recent commits

88b2235... by Alexander Barkov

MDEV-23287 The INET4 data type

975b40e... by Marko Mäkelä

Merge 10.9 into 10.10

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.

63961a0... by Marko Mäkelä

Merge 10.9 into 10.10

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.