[MDEV-17745] innodb.innodb_stats_persistent failed in buildbot with wrong result Created: 2018-11-16  Updated: 2020-10-27  Resolved: 2020-10-27

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Tests
Affects Version/s: 10.3
Fix Version/s: 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: purge

Issue Links:
Relates
relates to MDEV-16260 Scale the purge effort according to t... Open
relates to MDEV-16952 Introduce SET GLOBAL innodb_max_purge... Closed
relates to MDEV-18878 Purge is slow due to repeatedly looki... Closed
relates to MDEV-11802 innodb.innodb_bug14676111 fails in bu... Closed
relates to MDEV-12288 Reset DB_TRX_ID when the history is r... Closed
relates to MDEV-22958 innodb.instant_alter_debug fails in b... Closed

 Description   

http://buildbot.askmonty.org/buildbot/builders/kvm-fulltest-big/builds/2224

10.3 573c4db57a9b9fc5998bd2a2f1311873

 
innodb.innodb_stats_persistent 'innodb'  w2 [ fail ]
 
        Test ended at 2018-11-13 22:28:21
 
 
 
CURRENT_TEST: innodb.innodb_stats_persistent
 
--- /mnt/buildbot/build/mariadb-10.3.11/mysql-test/suite/innodb/r/innodb_stats_persistent.result	2018-11-13 07:59:56.000000000 -0500
 
+++ /mnt/buildbot/build/mariadb-10.3.11/mysql-test/suite/innodb/r/innodb_stats_persistent.reject	2018-11-13 22:28:20.782762345 -0500
 
@@ -67,7 +67,7 @@
 
 1	SIMPLE	t2	ref	val	val	4	const	1	Using index
 
 SET @saved_frequency = @@GLOBAL.innodb_purge_rseg_truncate_frequency;
 
 SET GLOBAL innodb_purge_rseg_truncate_frequency = 1;
 
-InnoDB		0 transactions not purged
 
+InnoDB		30 transactions not purged
 
 SET GLOBAL innodb_purge_rseg_truncate_frequency = @saved_frequency;
 
 # After COMMIT and purge, the DELETE must show up.
 
 EXPLAIN SELECT * FROM t1 WHERE val=4;
 
 
 
mysqltest: Result length mismatch



 Comments   
Comment by Marko Mäkelä [ 2018-11-16 ]

We still seem to have the ‘purge fails to run’ problem that was originally filed as MDEV-11802. With MDEV-12288 in 10.3, it can be observed also as a result of INSERT activity.

thiru, can you try to repeat this and determine what causes the failure to run? I think I have occasionally seen this on buildbot for other tests as well.

Comment by Marko Mäkelä [ 2019-03-11 ]

I believe that this particular failure can be attributed to the slowness of the system. The performance optimization in MDEV-18878 should help in other cases, but not this one, because the table is not being dropped, rebuilt, or discarded.

Comment by Elena Stepanova [ 2019-03-11 ]

Unfortunately it doesn't help much. Tests should be protected from moderate slowness, as there can always be circumstances when slow builders become even slower – not only in buildbot, but also in the build process performed by distributions (it was a big problem with Debian builds).

The only exception is when a builder is impossibly slow beyond any reason, so that tests fail massively, in which case the builder itself needs to be fixed. I don't think it applies here, though.

Comment by Marko Mäkelä [ 2019-03-11 ]

This one could help:
MDEV-16260 Scale the purge effort according to the workload

Comment by Marko Mäkelä [ 2019-03-11 ]

I extended the wait_all_purged.inc timeout from 30 to 60 seconds. That should reduce the probability of failures. A 60-second wait was enough to hide MDEV-18878 on the affected platform.

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

MDEV-22958 has been filed for the same problem, and I think that the solution is to implement a server-side wait for purge, by introducing a new SET GLOBAL variable, whose update trigger would implement the wait. The wait time can be limited by a statement timeout.

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

This should be fixed by MDEV-16952.

Generated at Thu Feb 08 08:38:47 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.