You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit be45bf2
Browse filesBrowse the repository at this point in the historyBrowse files
fix(parser/tidb): union SET columns across multi-DML rollback bundle
Per Codex P1 catch on PR #20345. backup.go's single-table path
(generateSQLForSingleTable, triggered when count > maxMixedDMLCount)
bundles multiple same-table DMLs into one PriorBackupDetail_Item
spanning Start[first] → End[last]. restore.go's findFirstDML then
returned only the FIRST DML node from the bundle, so the generated
ON DUPLICATE KEY UPDATE list included only that first stmt's
columns — columns mutated by LATER UPDATEs in the bundle were left
mutated, producing incomplete rollback for valid batched backups.
Fix:
(1) findFirstDML → findMatchingDMLs returns ALL UPDATE/DELETE nodes
referencing the target table (not just first).
(2) doGenerate accepts []ast.Node; partitions into UPDATE vs
DELETE. If any UPDATE exists in the bundle, generates ODKU
(pure INSERT SELECT would FAIL on the surviving UPDATE-modified
rows due to duplicate key); pure-DELETE bundles fall back to
INSERT SELECT (no surviving rows means no conflicts).
(3) generateUpdateRestore accepts []*ast.UpdateStmt; unions SET
columns across the bundle (case-insensitive dedup via lowercase
map; first-seen iteration order for deterministic ODKU output).
The disjoint-unique-key check operates on the union — if any
UPDATE in the bundle touched a column that overlaps every
unique key, the rollback is unsafe (same semantic as before,
just applied at the bundle level).
Existing fixtures still pass (their multi-stmt cases all touch
the same column → union = single column → identical output to the
pre-fix single-stmt path). New fixture pins the bug scenario:
6 UPDATEs on `test` interleaving SET a / SET b → expected ODKU
clause covers BOTH `a = VALUES(a), b = VALUES(b)`.
Mysql analog (mysql/restore.go) has the same multi-DML bug;
symmetric follow-up filed for parity.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments