Bug #84295 | The behavior is different when innodb_rollback_on_timeout=on | ||
---|---|---|---|
Submitted: | 21 Dec 2016 8:25 | Modified: | 6 Feb 2017 18:45 |
Reporter: | doller half | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Documentation | Severity: | S3 (Non-critical) |
Version: | 5.6.11,5.7.12 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[21 Dec 2016 8:25]
doller half
[19 Jan 2017 15:45]
MySQL Verification Team
Hi ! Thank you for your bug report. I was not able to find this change in behavior documented, so our manual requires to be updated.
[6 Feb 2017 18:45]
Daniel Price
Posted by developer: Enabling innodb_rollback_on_timeout does not cause a new transaction to be started in case of a deadlock timeout. The behavior in the reported example is described here: https://dev.mysql.com/doc/refman/5.6/en/innodb-error-handling.html "When a transaction rollback occurs due to a deadlock or lock wait timeout, it cancels the effect of the statements within the transaction. But if the start-transaction statement was START TRANSACTION or BEGIN statement, rollback does not cancel that statement. Further SQL statements become part of the transaction until the occurrence of COMMIT, ROLLBACK, or some SQL statement that causes an implicit commit." In the 5.6 example, trx_id 5401 is the I_S query. It is not a "new transaction". Transaction 5387 is the uncanceled transaction that was started with a BEGIN statement. In the 5.7 example, trx_id 422128392099664 is the uncanceled transaction that was started with a BEGIN statement. The innodb_rollback_on_timeout description was updated to include the quoted information noted above. https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_rollback_on_t... The change should appear online within 24 hours. Thank you for the bug report.