Bug #99751 | Statements after a deadlock | ||
---|---|---|---|
Submitted: | 1 Jun 2020 10:17 | Modified: | 21 Aug 2020 17:59 |
Reporter: | Eli Poultorak | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Documentation | Severity: | S3 (Non-critical) |
Version: | 8.0 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[1 Jun 2020 10:17]
Eli Poultorak
[1 Jun 2020 10:19]
Eli Poultorak
The links I included in the submission point to 5.7, however, the documentation in 8.0 says the same, and I found the bug in both versions.
[1 Jun 2020 13:08]
MySQL Verification Team
Hi Mr. Poultorak, Thank you for your documentation bug report. However, seems to me that our documentation is correct. It is the application itself that has to issue an explicit ROLLBACK in order to finish the transaction. This is not true only in the case when a deadlock or lock wait timeout causes the assert. I hope that I was clear enough.
[1 Jun 2020 13:09]
MySQL Verification Team
One more item. You have set a version for this but to be 8.0, while you quote a documentation for 5.7. Hence, which is it ????
[1 Jun 2020 14:01]
Eli Poultorak
Like I said before, both versions have the same behavior, and the documentation for both versions is wrong. After the deadlock error, the entire transaction is rolled back, and any statement after the deadlock error is committed automatically (assuming autocommit was 1 before the transaction started). However, according to the documentation, after the deadlock error, the transaction should still be open.
[1 Jun 2020 14:44]
MySQL Verification Team
Hi, I agree that this needs to be worded more correctly, so I am verifying this as a documentation bug. Verified.
[21 Aug 2020 17:59]
Daniel Price
Posted by developer: As stated above in the same section: "A transaction deadlock causes InnoDB to roll back the entire transaction." The conflicting text was removed. Changes should appear online soon. Thank you for the bug report.
[24 Aug 2020 12:09]
MySQL Verification Team
Thank you, Daniel.