Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2.5
Description
The field PAGE_MAX_TRX_ID only matters in secondary index leaf pages. It was expected to be 0 on all other pages until the field is put into some other use.
(MDEV-6076 repurposed the field in clustered index root pages for a persistent AUTO_INCREMENT value. MDEV-11369 and MDEV-11424 may repurpose it in further clustered index pages.)
When running innodb.innodb-wl5522-debug or innodb_zip.wl5522_debug_zip with innodb_page_size=4k, an assertion in btr_page_reorganize_low() is failing:
/* PAGE_MAX_TRX_ID must be zero on non-leaf pages other than
|
clustered index root pages. */
|
ut_ad(recovery
|
|| page_get_max_trx_id(page) == 0
|
|| (dict_index_is_sec_or_ibuf(index)
|
? page_is_leaf(temp_page)
|
: page_is_root(temp_page)));
|
An easy fix would be to relax the assertion:
/* PAGE_MAX_TRX_ID must be zero on non-leaf pages other than
|
clustered index root pages. */
|
ut_ad(recovery
|
|| page_get_max_trx_id(page) == 0
|
|| dict_index_is_sec_or_ibuf(index)
|
|| page_is_root(temp_page));
|
But I would like to study why this happens. Maybe we are not clearing PAGE_MAX_TRX_ID when splitting a secondary index leaf page.
Attachments
Issue Links
- causes
-
MDEV-12720 recovery fails with "Generic error" for ROW_FORMAT=compressed
- Closed
- relates to
-
MDEV-6076 Persistent AUTO_INCREMENT for InnoDB
- Closed
-
MDEV-20892 AUTO_INCREMENT is set lower than the max value of the primary_key
- Closed
-
MDEV-33277 In-place migration from MySQL 5.7 causes invalid AUTO_INCREMENT values
- Closed