Details
-
New Feature
-
Status: Open (View Workflow)
-
Critical
-
Resolution: Unresolved
-
None
-
None
-
Q3/2026 Server Development
Description
Step 2 of MDEV-39227
InnoDB Integration, Execution Flow, and Garbage Collection
- Estimated Effort: ~8-10 mandays
- Goal: Wire the new server-side capabilities to InnoDB's DDL execution flow to achieve the actual non-blocking ADD COLUMN INPLACE, and handle the cleanup of old metadata.
- Key Technical Tasks:
- DDL Commit Phase Rewrite: Modify the ALTER TABLE ... ADD COLUMN INPLACE completion phase. Instead of waiting for the exclusive MDL to atomically replace the table, it registers the new schema version in the server's data dictionary/TDC and makes it the default for new transactions.
InnoDB Mapping: Ensure InnoDB's internal handling (which already sees the old table definition during INPLACE operations) correctly maps to the server's schema versioning so data reads/writes route correctly. - Metadata Garbage Collection: Implement the cleanup logic. The server needs a safe way to detect when the last long-running transaction using the "old" schema version has committed or rolled back, so it can purge the old table definition from memory and drop the old MDLs.
- Replication/Binary Log Edge Cases: Ensure that the non-blocking commit phase writes to the binary log in a way that replicas can safely process without breaking consistency.
- DDL Commit Phase Rewrite: Modify the ALTER TABLE ... ADD COLUMN INPLACE completion phase. Instead of waiting for the exclusive MDL to atomically replace the table, it registers the new schema version in the server's data dictionary/TDC and makes it the default for new transactions.
Attachments
Issue Links
- split from
-
MDEV-39227 Implement per-transaction schema versioning to eliminate table-level DDL locks - Step 1
-
- In Progress
-