Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-41844

Test innodb.buf_pool_resize_pcur_restore is flaky

    XMLWordPrintable

Details

    • 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:

      https://buildbot.mariadb.org/cr/?branch=&revision=&platform=&dt=2026-09-01&max_dt=&bbnum=&typ=&info=&test_name=innodb.buf_pool_resize_pcur_restore&test_variant=&info_text=&failure_text=&limit=25&sort_order=desc#

      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

          Activity

            People

              thiru Thirunarayanan Balathandayuthapani
              alessandro.vetere Alessandro Vetere
              Alessandro Vetere Alessandro Vetere
              Thirunarayanan Balathandayuthapani Thirunarayanan Balathandayuthapani
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:

                Time Tracking

                  Estimated:
                  Original Estimate - 1d
                  1d
                  Remaining:
                  Time Spent - 1.5h Remaining Estimate - 6.5h
                  6.5h
                  Logged:
                  Time Spent - 1.5h Remaining Estimate - 6.5h
                  1.5h

                  Git Integration

                    Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.