Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
Description
The tests in the innodb_undo suite are apparently not run on buildbot, because I do not remember seeing any failures.
Furthermore, these tests should be rewritten to use wait_all_purged.inc instead of using innodb_fast_shutdown=0. Not only because restarting the server makes the test slower and harder to debug, but also because on 10.2, due to MDEV-13603, the slow shutdown could sometimes fail to run purge to completion, causing intermittent test failures.
Attachments
Issue Links
- relates to
-
MDEV-17679 innodb.undo_truncate_recover failed in buildbot with MySQL server has gone away on SHOW VARIABLES
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
Activity
As part of MDEV-13564, I already rewrote innodb_undo.truncate_recover, which must continue to restart the server 1 time. The 2 other tests can avoid restarting the server altogether.
The test innodb_undo.truncate is a subset of innodb_undo.truncate_multi_client, so the two tests can be merged. That would leave 2 tests in the innodb_undo suite. It is better to move those tests to the innodb suite, for example:
innodb.undo_truncate
innodb.undo_truncate_recover
I figured out the reason why the message "Truncation did not happen" is occasionally reported. There was no global status variable for reporting the number of undo tablespace truncation operations. The test could at most wait for the history list length to go to 0, but the actual truncation of the undo tablespace would happen later.
After adding a global status variable, the truncation reliably works for me with innodb_page_size 4k, 8k, 16k, and sometimes with 32k. For 64k, the amount of undo log generated by the test is too small, and the undo log tablespaces are not growing enough.
Once the tests are stable enough, they should be added to my @DEFAULT_SUITES in mysql-test/mysql-test-run.pl and possibly also to mysql-test/collections/buildbot_suites.bat for coverage on Windows.