Bug #69127 | InnoDB: possible regression in 5.5.31, Bug#16004999 | ||
---|---|---|---|
Submitted: | 2 May 2013 18:49 | Modified: | 29 May 2013 23:51 |
Reporter: | Calvin Sun | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: InnoDB storage engine | Severity: | S2 (Serious) |
Version: | 5.5.31 | OS: | Any |
Assigned to: | CPU Architecture: | Any | |
Tags: | regression, RQG |
[2 May 2013 18:49]
Calvin Sun
[2 May 2013 23:15]
MySQL Verification Team
Thank you for the bug report. Running against source server 5.5.32 I got a little different error message: 130503 2:09:48 [ERROR] /home/miguel/build20130426/mysql-5.5/sql/mysqld: Sort aborted: Deadlock found when trying to get lock; try restarting transaction 130503 2:09:49 [ERROR] /home/miguel/build20130426/mysql-5.5/sql/mysqld: Deadlock found when trying to get lock; try restarting transaction 130503 2:09:49 [ERROR] /home/miguel/build20130426/mysql-5.5/sql/mysqld: Sort aborted: Deadlock found when trying to get lock; try restarting transaction 130503 2:09:53 [ERROR] /home/miguel/build20130426/mysql-5.5/sql/mysqld: Deadlock found when trying to get lock; try restarting transaction 130503 2:09:53 [ERROR] /home/miguel/build20130426/mysql-5.5/sql/mysqld: Sort aborted: Deadlock found when trying to get lock; try restarting transaction 130503 2:09:54 InnoDB: Assertion failure in thread 139760589625088 in file ha_innodb.cc line 5622 InnoDB: Failing assertion: prebuilt->trx->conc_state == 1
[24 May 2013 13:40]
Paul DuBois
Changes for test suite. No changelog entry needed. Will note in refman that INFORMATION_SCHEMA.INNODB_TRX is updated once per second.
[24 May 2013 13:46]
Calvin Sun
The newly added comment does not make any sense for this bug. Need explanation why it is closed. Reopen it.
[24 May 2013 15:00]
Paul DuBois
Correction: Table updates are each .1 second, not each second.
[24 May 2013 15:06]
Paul DuBois
Noted in 5.5.32, 5.6.13, 5.7.2 changelogs. If an UPDATE with a subquery caused a deadlock inside InnoDB, the deadlock was not properly handled by the SQL layer. The SQL layer then tried to unlock the row after InnoDB rolled back the transaction, raising an assertion inside InnoDB.