The following test is simulating an earlier bug that was fixed in MDEV-36038.
--source include/have_innodb.inc
|
let $datadir=`select @@datadir`;
|
CREATE SEQUENCE t1 engine=innodb;
|
--copy_file $datadir/test/t1.frm $datadir/test/t2.frm
|
ALTER TABLE t1 sequence=0;
|
--connect (prevent_purge,localhost,root)
|
START TRANSACTION WITH CONSISTENT SNAPSHOT;
|
--connection default
|
UPDATE t1 SET start_value=42;
|
FLUSH TABLES;
|
--remove_file $datadir/test/t1.frm
|
--move_file $datadir/test/t2.frm $datadir/test/t1.frm
|
SHOW CREATE TABLE t1;
|
CHECK TABLE t1;
|
--disconnect prevent_purge
|
#DROP SEQUENCE t1;
|
This test will not execute any check:
CHECK TABLE t1;
|
Table Op Msg_type Msg_text
|
test.t1 check note The storage engine for the table doesn't support check
|
After the test completes, you can check with
od -j0xc000 -Ax -t x1 var/mysqld.1/data/test/t1.ibd
|
that the first 6+6+7 bytes of the record payload (DB_ROW_ID,DB_TRX_ID,DB_ROLL_PTR) are not (0x200,0,1<<55) . The DB_ROW_ID is 0x200, but the DB_TRX_ID is nonzero and the DB_ROLL_PTR is associated with an UPDATE (the most significant bit is not set).
Hi marko, based on the MDEV-36032 patch[1], in relation to your comment[2] in MDEV-35866, could you provide a testcase for this issue?
[1] https://jira.mariadb.org/browse/MDEV-36032?focusedCommentId=303182&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-303182
[2] https://jira.mariadb.org/browse/MDEV-35866?focusedCommentId=302977&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-302977