Bug #56541 | Assertion table->db_stat failed in sql_base.cc::open_table() during I_S queries | ||
---|---|---|---|
Submitted: | 3 Sep 2010 15:05 | Modified: | 19 Apr 2011 17:26 |
Reporter: | John Embretsen | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Information schema | Severity: | S1 (Critical) |
Version: | 5.1.48 | OS: | Any |
Assigned to: | CPU Architecture: | Any | |
Tags: | RQG |
[3 Sep 2010 15:05]
John Embretsen
[3 Sep 2010 15:11]
John Embretsen
Full test output with stacktraces from CDB dump (mysql-5.1-bugteam).
Attachment: bug56541_log_rqg_info_schema_5.1-bugteam.txt (text/plain), 94.70 KiB.
[3 Sep 2010 15:39]
John Embretsen
Two simultaneous client threads (RQG option --threads=2) is enough to reproduce the issue. Also seen on Unix, hence not limited to Windows, and not likely the exact same cause as Bug#56540 (which does not seem to occur on Unix). In one situation the 2 queries executed at the time of the assertion were: SELECT * FROM (test . `D` AS table1 STRAIGHT_JOIN INFORMATION_SCHEMA . `PARTITIONS` AS table2 ON ( table2 . `PARTITION_DESCRIPTION` = table1 . `col_time_nokey` ) ) WHERE NOT (NOT table1 . `col_time_nokey` = 8 AND table1 . `col_date_key` >= table1 . `col_varchar_key`) ORDER BY table1 . `col_date_nokey` , table2 . `TABLE_NAME` ; and CREATE TRIGGER i BEFORE INSERT ON `D` FOR EACH ROW BEGIN INSERT INTO `DD` SELECT * FROM `B` LIMIT 0 ; END ; or DROP TRIGGER IF EXISTS x; so it seems SHOW TABLE STATUS is not a required property of this bug (but perhaps a STRAIGHT_JOIN query is). Synopsis modified accordingly.
[3 Sep 2010 15:48]
MySQL Verification Team
on Fedora X86_64
Attachment: core56541.txt (text/plain), 33.38 KiB.
[3 Sep 2010 23:11]
MySQL Verification Team
Thank you for the bug report.
[6 Sep 2010 11:13]
John Embretsen
I ran the bzrfind tool on mysql-5.1-bugteam in order to find the cause of this regression. The tool replied: # Regression source: mattias.jonsson@sun.com-20100317141041-o1629etmqbe8mpbq $ bzr log -v -r revid:mattias.jonsson@sun.com-20100317141041-o1629etmqbe8mpbq ------------------------------------------------------------ revno: 3351.44.1 committer: Mattias Jonsson <mattias.jonsson@sun.com> branch nick: b50561-51-bugteam_name_lock_fix timestamp: Wed 2010-03-17 15:10:41 +0100 message: Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with concurrent I_S query There were two problem: 1) MYSQL_LOCK_IGNORE_FLUSH also ignored name locks 2) there was a race between abort_and_upgrade_locks and alter_close_tables (i.e. remove_table_from_cache and close_data_files_and_morph_locks) Which allowed the table to be opened with MYSQL_LOCK_IGNORE_FLUSH flag resulting in renaming a partition that was already in use, which could cause the table to be unusable. Solution was to not allow IGNORE_FLUSH to skip waiting for a named locked table. And to not release the LOCK_open mutex between the calls to remove_table_from_cache and close_data_files_and_morph_locks by merging the functions abort_and_upgrade_locks and alter_close_tables. added: mysql-test/suite/parts/r/partition_debug_sync_innodb.result mysql-test/suite/parts/t/partition_debug_sync_innodb-master.opt mysql-test/suite/parts/t/partition_debug_sync_innodb.test modified: sql/authors.h sql/ha_partition.cc sql/mysql_priv.h sql/sql_base.cc sql/sql_partition.cc sql/sql_show.cc This was pushed to mysql-5.1-bugteam 2010-05-10.
[19 Apr 2011 17:26]
Paul DuBois
Noted in 5.1.57, 5.5.12, 5.6.3 changelogs. An assertion could be raised if a statement that required a name lock on a table (for example, DROP TRIGGER) executed concurrently with an INFORMATION_SCHEMA query that also used the table. CHANGESET - http://lists.mysql.com/commits/134121
[20 Apr 2011 14:47]
Paul DuBois
Correction: This was fixed only in 5.1.57.