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
-
-
- Closed
-
- relates to
-
MDEV-6076 Persistent AUTO_INCREMENT for InnoDB
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
Activity
| Summary | Secondary index node pointer page contains nonzero PAGE_MAX_TRX_ID | Page contains nonzero PAGE_MAX_TRX_ID |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | In Review [ 10002 ] |
bb-10.2-marko rebased to latest 10.2 (fixing a result after MDEV-11995). No change to the patch.
| Assignee | Marko Mäkelä [ marko ] | Jan Lindström [ jplindst ] |
| Assignee | Jan Lindström [ jplindst ] | Marko Mäkelä [ marko ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
This bug impacts MDEV-6076 (persistent AUTO_INCREMENT) when using IMPORT TABLESPACE with data files on which IMPORT TABLESPACE has been used before MariaDB 10.2.6. In those cases, the AUTO_INCREMENT value will be restored to a bogus value (something that was a transaction ID in the previous IMPORT).
| issue.field.resolutiondate | 2017-04-19 05:20:58.0 | 2017-04-19 05:20:58.433 |
| Fix Version/s | 10.2.6 [ 22527 ] | |
| Fix Version/s | 10.2 [ 14601 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
| Link |
This issue causes |
| Workflow | MariaDB v3 [ 79743 ] | MariaDB v4 [ 151746 ] |
| Link |
This issue relates to |
| Link |
This issue relates to |
With innodb_page_size=32k and innodb_page_size=64k, also the relaxed assertion is failing for innodb.innodb-wl5522-debug, for the clustered index.
In the clustered index the PAGE_MAX_TRX_ID field should always have been 0 until
MDEV-6076repurposed it for the root page only:2017-02-24 12:46:44 140590992532224 [Note] InnoDB: Phase II - Purge records from index `PRIMARY`2017-02-24 12:46:44 0x7fdde42b2300 InnoDB: Assertion failure in file /mariadb/server/storage/innobase/btr/btr0btr.cc line 1625InnoDB: Failing assertion: recovery || page_get_max_trx_id(page) == 0 || dict_index_is_sec_or_ibuf(index) || page_is_root(temp_page)