Details
-
Bug
-
Status: In Review (View Workflow)
-
Minor
-
Resolution: Unresolved
-
10.11
-
None
-
Not for Release Notes
-
Q4/2026 Server Development
Description
Test innodb.buf_pool_resize_pcur_restore which I added in MDEV-41398 is flaky on slow builders:
The failure mode in all cases is a "known" one, which the 5 attempts in the stored procedure loop inside the test was meant to fix (and it didn't):
innodb.buf_pool_resize_pcur_restore w55 [ fail ]
|
Test ended at 2026-10-23 02:24:19
|
 |
CURRENT_TEST: innodb.buf_pool_resize_pcur_restore
|
mysqltest: At line 156: query 'call read_into_first_new_block('t2')' failed: ER_SIGNAL_EXCEPTION (1644): Wrong placement
|
Patch below is enough to make the test ~always fail with the same mode (attempts are useless):
--- a/mysql-test/suite/innodb/t/buf_pool_resize_pcur_restore.test
|
+++ b/mysql-test/suite/innodb/t/buf_pool_resize_pcur_restore.test
|
@@ -90,6 +90,7 @@ begin
|
select pk into @n from t3 where pk= p;
|
set p= p + 1;
|
end while;
|
+ do sleep(1.5);
|
execute read_tbl;
|
select block_id into blk from information_schema.innodb_buffer_page
|
where table_name = concat('`test`.`', tbl, '`'); |
What is happening (checked using rr) is that purge is "stealing" the block that the test needs. While history exists, the purge coordinator wakes up once per second. It reads undo log pages (trx_purge()), and it submits purge_truncation_callback(), which reads all rollback segment header pages (purge_sys_t::iterator::free_history()).
This patch (+ .result record) seems enough to correct the situation:
--- a/mysql-test/suite/innodb/t/buf_pool_resize_pcur_restore.test
|
+++ b/mysql-test/suite/innodb/t/buf_pool_resize_pcur_restore.test
|
@@ -101,6 +101,15 @@ delimiter ;|
|
# Purge resets DB_TRX_ID in the inserted records. Let it finish, so that it
|
# reads no pages into the free blocks that the procedure counts.
|
set global innodb_max_purge_lag_wait= 0;
|
+# Stop purge. While history exists, the purge coordinator runs once per
|
+# second. It reads undo log pages and the header page of each rollback
|
+# segment, and these reads can take the free blocks that the procedure
|
+# counts. A read view does not stop these reads. FLUSH TABLES ... FOR
|
+# EXPORT stops the purge coordinator.
|
+create table t5 (a int) engine=innodb;
|
+connect (stop_purge,localhost,root);
|
+flush tables t5 for export;
|
+connection default;
|
|
set @old_size= @@global.innodb_buffer_pool_size;
|
set @new_size= 12582912;
|
@@ -133,9 +142,6 @@ connection con1;
|
--reap
|
connection default;
|
set global innodb_buffer_pool_size= @old_size;
|
-# Purge was blocked by the read view of the paused read. Let it finish, so
|
-# that it reads no pages into the new blocks of the next case.
|
-set global innodb_max_purge_lag_wait= 0;
|
|
--echo #
|
--echo # An UPDATE that continues from a stale position
|
@@ -165,9 +171,13 @@ connection default;
|
select group_concat(pk) from t2 where val = 'b';
|
|
set debug_sync= 'reset';
|
+connection stop_purge;
|
+unlock tables;
|
+disconnect stop_purge;
|
+connection default;
|
drop procedure read_into_first_new_block;
|
drop function hold;
|
-drop table t1, t2, t3, t4;
|
+drop table t1, t2, t3, t4, t5;
|
set global innodb_buffer_pool_size= @old_size;
|
set global innodb_lru_scan_depth= @save_scan_depth;
|
--source include/wait_until_count_sessions.inc |
So it's a test case issue, not an issue with the code contributed via MDEV-41398.
The analysis of the issue, as well as the patch, was AI-assisted.
Attachments
Issue Links
- is caused by
-
MDEV-41398 Optimistic btr_pcur_t restore accepts a stale position after the buffer pool shrinks and grows again
-
- Closed
-