Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.6
-
None
Description
main.mysqldump-system fails regularly in buildbot starting from 10.6
This is probably related to marko enabling persistent statistics in 10.6.
A typical failure (I have copied the part that is easiest to read):
LOCK TABLES `innodb_table_stats` WRITE;
|
/*!40000 ALTER TABLE `innodb_table_stats` DISABLE KEYS */; |
-REPLACE INTO `innodb_table_stats` VALUES ('mysql','tz','2019-12-31 21:00:00',393,1,0); |
+REPLACE INTO `innodb_table_stats` VALUES ('mysql','tz','2019-12-31 21:00:00',393,1,0),('test','#mysql50##sql-alter-25ff1-12e','2024-04-08 21:14:50',0,1,0); |
/*!40000 ALTER TABLE `innodb_table_stats` ENABLE KEYS */; |
This is from mysqldump and the bug is that somehow innodb stats tables contains
references to temporary tables that has been deleted a long time ago.
This bug is hard to find as in most case the wrong value in innodb_table_stats will
not be noticed by mtr. There are very few test cases, like main.mysqldump-system that
exposes this problem.
One way to make it easier to find this, and similar bugs, is to add a DBUG_ASSERT, when we update innodb_table_stats and innodb_index_stats, to check that the table name does not contain the string '##sql-alter'. This assert would only enabled in DBUG builds.
Having this assert would allow us to find the test case that causes this, which would help finding and fixing the bug.
In other words, this jira entry is in two parts:
- Add a DBUG_ASSERT
- When the DBUG_ASSERT is triggered in buildbot, fix the real bug.
Attachments
Issue Links
- is part of
-
MDEV-33073 always green buildbot
- Stalled