mirror of
https://github.com/MariaDB/server.git
synced 2025-01-22 06:44:16 +01:00
d0ef1aaf61
When MDEV-6076 repurposed the field PAGE_MAX_TRX_ID, it was assumed that the field always was 0 in the clustered index of old data files. This was not the case in IMPORT TABLESPACE (introduced in MySQL 5.6 and MariaDB 10.0), which is writing the transaction ID to all index pages, including clustered index pages. This means that on a data file that was at some point of its life IMPORTed to an InnoDB instance, MariaDB 10.2.4 or later could interpret the transaction ID as a persistent AUTO_INCREMENT value. This also means that future changes that repurpose PAGE_MAX_TRX_ID in the clustered index may cause trouble with files that were imported at some point of their life. There is a separate minor issue that InnoDB is writing PAGE_MAX_TRX_ID to every secondary index page, even though it is only needed on leaf pages. From now on we will write PAGE_MAX_TRX_ID as 0 to non-leaf pages, just to be able to keep stricter debug assertions. btr_root_raise_and_insert(): Reset the PAGE_MAX_TRX_ID field on non-root pages of the clustered index, and on the no-longer-leaf root page of secondary indexes. AbstractCallback::is_root_page(): Remove. Use page_is_root() instead. PageConverter::update_index_page(): Reset the PAGE_MAX_TRX_ID to 0 on other pages than the clustered index root page or secondary index leaf pages. |
||
|---|---|---|
| .. | ||
| row0ext.cc | ||
| row0ftsort.cc | ||
| row0import.cc | ||
| row0ins.cc | ||
| row0log.cc | ||
| row0merge.cc | ||
| row0mysql.cc | ||
| row0purge.cc | ||
| row0quiesce.cc | ||
| row0row.cc | ||
| row0sel.cc | ||
| row0trunc.cc | ||
| row0uins.cc | ||
| row0umod.cc | ||
| row0undo.cc | ||
| row0upd.cc | ||
| row0vers.cc | ||