Bug #75540 | Major regression having many row versions | ||
---|---|---|---|
Submitted: | 17 Jan 2015 21:07 | Modified: | 29 Jan 2015 1:33 |
Reporter: | Peter Zaitsev | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Server: InnoDB storage engine | Severity: | S4 (Feature request) |
Version: | 5.6 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[17 Jan 2015 21:07]
Peter Zaitsev
[20 Jan 2015 20:37]
Sveta Smirnova
Thank you for the report. Which exact version of 5.6 do you use? Please also provide all InnoDB-related and replication-related options you used.
[21 Jan 2015 5:11]
MySQL Verification Team
I've seen this many times. you must first get your "history list length" into the millions. this can be done by continuously updating a row many times in a transaction while tests are running.
[21 Jan 2015 14:34]
MySQL Verification Team
This is a very well known bottleneck that required changes in current design. The new design has been described in several WorkLog entries for the purpose. It will require a new UNDO log design to get fixed. Purge will need to skip the blocking transaction and delete the UNDO entries that are no longer needed. It is contained in several WL # entries, like 5742. Verified as a feature request.
[29 Jan 2015 1:33]
Peter Zaitsev
Thank you Sinisa!