General
Escalation
General
Escalation
Description
Environment
None
Activity
Show:
Satya Bodapati June 27, 2024 at 2:10 PM
Pasting the slack discussion here:
Yura Sorokin June 25, 2024 at 9:58 PM
Yura Sorokin May 20, 2024 at 12:06 PM
Aaditya Dubey May 2, 2024 at 9:44 AM
Hi
Thank you for the report.
Verified as described.
marc reilly May 1, 2024 at 4:50 PM
8.4.0 stack for search-ability:
Done
Pinned fields
Click on the next to a field label to start pinning.
Details
Assignee
Reporter
Labels
Regression Issue
Yes
Upstream Bug URL
Needs QA
Yes
Sprint
None
Fix versions
Affects versions
Priority
High
Smart ChecklistOpen Smart Checklist
Open Smart Checklist
Created May 1, 2024 at 3:48 PM
Updated August 28, 2024 at 2:26 PM
Resolved July 5, 2024 at 11:55 AM
FYI for when 8.0.37 merging starts, another INSTANT DDL regression .
Originally reported here which is now private: https://bugs.mysql.com/114837
Summary
Executing a instant DDL followed by a UPDATE will lead to an assertion failure on upstream 8.0.37. Haven't dug into it yet but I suspect it may be related to how INSTANT DDL column ordering issue fixed in 8.0.37
8.0.27 INSTANT DDL Upstream fixes:
InnoDB: The redo log would potentially not log a column order change with instant DDL, which could cause an incorrect log replay during recovery. (Bug #35183686)
8-0-37 tag is not on github yet but here is the 8.4.0 fix:
Bug: https://bugs.mysql.com/bug.php?id=113442
There was also this instant fix related to instant, which has been in innovation release since 8.2:
InnoDB: If a MySQL table in a system schema had an INSTANT ADD column that was added before 8.0.29 (they are not allowed as of that version), and after MySQL was upgraded to a version greater than 8.0.29, DMLs on these tables would result in the server unexpectedly closing.
Our thanks to Richard Dang for the contribution. (Bug #35625510, Bug #35981565, Bug #36180360)
Bug:
Repro
Note that rebuilding the table post restart seems to resolve this specific INSTANT ddl operation.
stack
Forcing INPLACE DDL does not crash