[MDEV-22958] innodb.instant_alter_debug fails in buildbot with wrong result Created: 2020-06-19  Updated: 2020-10-27  Resolved: 2020-10-27

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Tests
Affects Version/s: 10.5
Fix Version/s: 10.2.35, 10.3.26, 10.4.16, 10.5.7

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-16678 Use MDL for innodb background threads... Closed
relates to MDEV-16952 Introduce SET GLOBAL innodb_max_purge... Closed
relates to MDEV-17745 innodb.innodb_stats_persistent failed... Closed

 Description   

http://buildbot.askmonty.org/buildbot/builders/winx64-debug/builds/19611

10.5 359d5f56c315cbc428e96d5d2d83d5a7

 
innodb.instant_alter_debug 'innodb'      w4 [ fail ]
 
        Test ended at 2020-06-15 16:15:58
 
 
 
CURRENT_TEST: innodb.instant_alter_debug
 
--- D:/winx64-debug/build/src/mysql-test/suite/innodb/r/instant_alter_debug.result	2020-06-15 15:19:41.830087100 +0000
 
+++ D:\winx64-debug\build\src\mysql-test\suite\innodb\r\instant_alter_debug.reject	2020-06-15 16:15:57.896423800 +0000
 
@@ -204,7 +204,7 @@
 
 COMMIT;
 
 connection default;
 
 SET DEBUG_SYNC = 'now WAIT_FOR copied';
 
-InnoDB		1 transactions not purged
 
+InnoDB		2 transactions not purged
 
 INSERT INTO t1 SET a=1;
 
 INSERT INTO t1 SET a=2,b=3,c=4;
 
 SET DEBUG_SYNC = 'now SIGNAL logged';
 
 
 
mysqltest: Result content mismatch



 Comments   
Comment by Marko Mäkelä [ 2020-09-03 ]

This seems to occur most often on win32-debug, but also kvm-fulltest2 is failing every now and then. I think that only with an rr replay trace we could fix this. Failures are rather infrequent, about once in one or two weeks.
Because this test seems to fail on 10.5 only while the test should be similar in 10.4 or even 10.3, MDEV-16678 could have something to do with this.

Comment by Marko Mäkelä [ 2020-09-11 ]

I analyzed an rr replay trace for a similar failure of innodb.undo_truncate. In that trace, the history was eventually shrunk to 0, shortly before the server was killed. The test had failed with a result difference showing a history list length of 3.

There might be no actual hang in the server, and could we merely have an overloaded system. It certainly does not help to ask the server ‘are we there yet? give me a full status report’ 10 times per second, throwing out most of the lengthy SHOW ENGINE INNODB STATUS output.

wlad suggested that we could introduce a special SET GLOBAL variable for waiting for the purge to complete. It could be useful also for end users who want to ensure that any purge of history will complete before starting something special, such as executing a large join that is making extensive use of secondary indexes. Purge lag can really hurt such operations; see MDEV-20301.

Comment by Marko Mäkelä [ 2020-10-27 ]

This should be fixed by MDEV-16952.

Generated at Thu Feb 08 09:18:46 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.