InnoDB changes between MySQL 8.4.11 and MySQL 8.4.13

There was no tagged MySQL 8.4.12 release. https://dev.mysql.com/doc/relnotes/mysql/8.4/en/news-8-4-12.html mentions the following:

This release is a Critical Security Patch Update for the MySQL Server docker image, only. See Oracle Critical Security Patch Update Advisory - August 2026 for more information.

Even though there are no public releases, Oracle still appears to maintain a MySQL 8.0 branch, to which most InnoDB changes have been applied. The latest merge of the 8.0 branch that is available in the public is for Bug#39905175 Bound CTE reparsing during parsing, which changes something outside InnoDB.

MySQL 8.4 changes not affecting MariaDB

34edd302d16 Merge branch 'mysql-8.0' into mysql-8.4

0b3e2658767 Merge branch 'mysql-8.0' into mysql-8.4

86a51417530 Merge branch 'mysql-8.0' into mysql-8.4

88c70613862 BUG#39848832: InnoDB: crash_after_log_ibuf_upd_inplace crashes before redo log is produced

dd46ef24d60 Merge branch 'mysql-8.0' into mysql-8.4

9cf29a64dd7 Merge branch 'mysql-8.0' into mysql-8.4

a54cdc625b8 Merge branch 'mysql-8.0' into mysql-8.4

2e533d49940 Merge branch 'mysql-8.0' into mysql-8.4

038019f8ea9 BUG#39673496: MTR innodb.disable_log_encryption sporadically fails with result mismatch

6dd4a3a1ad4 Merge branch 'mysql-8.0' into mysql-8.4

1b3aa1940ca Merge branch 'mysql-8.0' into mysql-8.4

c889d0642d2 Merge branch 'mysql-8.0' into mysql-8.4

fa50a23bda5 Merge branch 'mysql-8.0' into mysql-8.4

8c231ae017a Merge branch 'mysql-8.0' into mysql-8.4

44c05d47372 Merge branch 'mysql-8.0' into mysql-8.4

1e582536a22 Bug#36396562        innodb.sdi_compressed test with innodb_doublewrite=OFF causes Assertion failure: buf0buf.cc:3243:!bpage->was_stale()

d540ca720d0 Merge branch 'mysql-8.0' into mysql-8.4

...

Other than merges from the 8.0 branch since the MySQL 8.4.11 release, the above lists the following 3 changes, listed below in the opposite order (oldest first):

Bug#36396562 innodb.sdi_compressed test with innodb_doublewrite=OFF causes Assertion failure: buf0buf.cc:3243:!bpage->was_stale()
The SDI metadata is specific to the MySQL 8.0 Global Data Dictionary. MariaDB Server implemented MDEV-17567 Atomic DDL in a different way, without extensive changes to the data dictionary format. The test case is specific to ALTER TABLE...IMPORT TABLESPACE of a ROW_FORMAT=COMPRESSED table. This changes something related to a buf_page_t::was_stale() check. That predicate had been introduced in WL#14100 - InnoDB: Faster truncate/drop table space, which extends WL#11819: Support ACID Undo DDL. In MariaDB Server, MDEV-13564 fixed these regressions in a completely different way.

BUG#39673496: MTR innodb.disable_log_encryption sporadically fails with result mismatch
In MariaDB Server, innodb_encrypt_log uses a totally different implementation (last revised in MDEV-36024). We do not currently support SET GLOBAL innodb_encrypt_log at all; changing the encryption requires a server restart.

BUG#39848832: InnoDB: crash_after_log_ibuf_upd_inplace crashes before redo log is produced
The change buffer was disabled by default in MDEV-27734 and removed in MDEV-29694. The only currently maintained release that supports it is MariaDB Server 10.11. This change removes the fault injection crash_after_log_ibuf_upd_inplace from the function ibuf_insert_to_index_page() and adjusts a regression test. In MariaDB, there is no test that would exercise this crash injection point, so it is kind of dead code already, and only affecting CMAKE_BUILD_TYPE=Debug anyway.

The following command will list the InnoDB changes in the 8.0 branch since the previous release:

git log --oneline mysql-8.4.11..6c3848b84ed8e5d19ad4e4e0aea2ff98519d747b storage/innobase

MySQL 8.0 changes not affecting MariaDB

Bug#39249507 Regression : "Row size too large (> 8126)" error with table using InnoDb DYNAMIC row format
This is a follow-up to an earlier change Bug#39129182 Mysqld Crash due to "Deadlock Detected!" Error that we rejected in MDEV-40618. The revision is that the size check will no longer be applied to ALTER TABLE...ALGORITHM=INSTANT, which in MySQL 8.0 was implemented in a completely different way from our MDEV-11369 and MDEV-15562.

Bug#39661792 Assertion failure: btr0sea.cc:1082:block->page.id.space() == index->space
MDEV-12266 removed the redundant field index->space as well as the problematic assignment in row_import_cleanup(), which in MySQL 8.0 was moved to a separate function row_import_discard_changes().

Bug#39661793 Rows from discarded tablespace remain visible after importing old tablespace
There is no test case. The described scenario is that a tablespace is exported, some modifications made to the table, and an older version of the tablespace is imported with the same tablespace ID. The adaptive hash index would wrongly return data that was in the table before it was reverted to an earlier version. Our implementation of MDEV-22456 mentions this very scenario, showing that MariaDB is not affected:

Related to this, in MDEV-16283, we made ALTER TABLE...DISCARD TABLESPACE skip both the buffer pool eviction and the drop of the adaptive hash index. We shifted the burden to ALTER TABLE...IMPORT TABLESPACE or DROP TABLE. We can remove the eviction from DROP TABLE. We must retain the eviction in the ALTER TABLE...IMPORT TABLESPACE code path, so that in case the discarded table is being re-imported with the same tablespace identifier, the fresh data from the imported tablespace will replace any stale pages in the buffer pool.

Instead of introducing a conditional branch to a frequently executed code path like Oracle did on MySQL, MariaDB chose to make a rare operation slightly slower.

Bug#39295605 InnoDB: offsets read from input page of transportable tablespace are not validated (fixup)
This is tweaking something related to the MySQL 8.0 specific implementation of ALTER TABLE...ALGORITHM=INSTANT. In MySQL, there is no equivalent fix to MDEV-13542 or MDEV-21098. The latter should report errors instead of crashing on all code path that involve following next-record links.

BUG#39632565: Low-privilege user crashes server (SIGSEGV) via typed NULL to innodb_redo_log_consumer_advance
This fixes up WL#12527 InnoDB: Dynamic configuration of space occupied by redo log files. MDEV-27812 implemented SET GLOBAL innodb_log_file_size without changing the log format, and MDEV-21923 removed the last major log write scalability bottleneck without abandoning the single-file format. This bug is specific to the MySQL jungle of threads and files: https://dev.mysql.com/blog-archive/mysql-8-0-new-lock-free-scalable-wal-design/

Bug#39729888 i_s_fts_index_cache_fill can read memory freed by fts_sync
This fixes up Bug #31310404 I_S_FTS_INDEX_CACHE_FILL_ONE_INDEX() IS NOT PROTECTED BY THE LOCK which we noted here was fixed in a cleaner way in MDEV-22765, by protecting the cache access with a shared latch. This is what the follow-up fix from Oracle does 6 years later.

Bug#39134921 Foreign key insert error causes crash
This fixes a race condition between a SELECT from a grandparent table and ALTER TABLE...ALGORITHM=COPY on a grandchild table. If the scenario affects MariaDB at all (our data dictionary cache is different), it should be fixed by MDEV-37365. For MySQL, a better fix should have been to follow up WL#6049 by acquiring MDL_EXCLUSIVE on all related tables on the ALTER TABLE code path.

Bug#36672483 InnoDB: Assert transaction in LOB partial updates
This is specific to WL#8960 partial BLOB updates and the WL#9141 BLOB storage format that does not exist in MariaDB Server.

Bug#39091341: Rename the column of the foreign key will result mysql crash
This fixes up Bug#28581468 - RENAMING PARENT COLUMN IN A FOREIGN KEY FAILS WITH STRANGE ERROR, which mentions the following:

This is finally proved to be a regression from new DD work, which mistakenly removed the foreign key cache invalidation for the rebuild ALTER TABLE.

The "Global Data Dictionary" was never implemented in MariaDB; instead, MDEV-17567 and related tasks achieved crash-safe DDL operations by other means.

Bug#37258813 btr_page_reorganize_low may cause crash recovery failure
This introduces an intentional crash in case corruption is noticed during a page reorganize operation, which is the exact opposite of MDEV-18519. MDEV-12353 changed the way how these operations are recovered in MariaDB. In any case, I filed MDEV-41661 so that on failure, btr_page_reorganize_low() will restore the page as it was and free the block that it had allocated.

Bug#39362553 Debug assertion failure in row_log_table_apply_convert_mrec
This is a duplicate of MDEV-21539, which we fixed back in 2020. The failing assertion in the function row_log_table_apply_convert_mrec() had been added by me in 2012, as part of implementing the online table rebuild, WL#6255. The test scenario is as follows:

CREATE TABLE t1 (f VARCHAR(8) CHARACTER SET latin1 COLLATE latin1_swedish_ci)

ENGINE=InnoDB;

ALTER TABLE t1 MODIFY f VARCHAR(256) COLLATE latin1_german2_ci NOT NULL;

The introduction of NOT NULL forces a table rebuild. The change of collation would only matter if the column was indexed. The encoding is unchanged. Side note: MDEV-15250 simplified this area a lot, removing the tracking of BLOB operations, because UndorecApplier will replicate all changes at transaction commit time.

Bug#39123849 Contribution by Tencent: mem_heap_alloc function alloc more than 4GB memory leak
This fixes a regression that was introduced in MySQL 8.0.29 by WL#14680 - Removing #defines from InnoDB, by changing constexpr uint32_t UNIV_MEM_ALIGNMENT = 8 to use the more appropriate type size_t. In MariaDB Server, the definition was never changed.

[BUG#37380231: dd_tablespace_update_cache will create fil_space_t for discard
ed tablespace lead import tablespace crash|https://github.com/mysql/mysql-server/commit/7e3ce4065786304757e7493e4dc401cface98fa1]
This is specific to the Global Data Dictionary that was introduced in MySQL 8.0, breaking compatibility with MySQL 5.7 as well as MariaDB Server.

MySQL 8.0 changes affecting MariaDB

Bug#38547442: Assertion failure: fts0fts.cc:2447:result != FTS_INVALID (fixup)
Filed as MDEV-41665, whose test case uses DELETE IGNORE instead of UPDATE IGNORE that is mentioned by Oracle, who did not release a test case.

Bug#39234789 MySQL 8.0.45 - InnoDB FTS Boolean Mode Stack Overflow → mysqld SIGSEGV
This is related to MDEV-41281.

Bug#39147834 statement rollback on indexed virtual columns will crash when FK ON UPDATE SET NULL hits duplicate key on parent update
Filed as MDEV-41666.

BUG#39593341: InnoDB crashes with assertion failure when UPDATE touches a table with many secondary indexes
Filed as MDEV-41667.

Bug#36999166 ALTER TABLE ... IMPORT TABLESPACE may cause unsafe reads
Filed as MDEV-41669.