feat(multi_update): optional __mo_cpkey_col consistency assertion to diagnose duplicate PK (#24975)#24994
Open
ck89119 wants to merge 2 commits into
Open
feat(multi_update): optional __mo_cpkey_col consistency assertion to diagnose duplicate PK (#24975)#24994ck89119 wants to merge 2 commits into
ck89119 wants to merge 2 commits into
Conversation
…diagnose duplicate PK (matrixorigin#24975) Add an optional, default-off runtime check in the main-table insert path (check_null_and_insert_main_table). For composite-PK tables it recomputes serial(pk cols) per written row and compares against the __mo_cpkey_col being inserted; on mismatch (a row whose stored composite key does not match its own primary-key columns) it logs or panics, controlled by env MO_DEBUG_CPKEY_ASSERT: - unset / anything else (default): off, no per-row overhead - "log": log an error on mismatch, keep running - "panic": log + panic on mismatch (dumps stack to locate the cause) This is a diagnostic to catch the genesis of the duplicate-primary-key corruption reported in matrixorigin#24975 at the moment a misaligned row is written. It does not change execution behavior when disabled and is not a fix for the root cause. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
Which issue(s) this PR fixes:
related to issue #24975 (diagnostic only — this PR does not fix the root cause)
What this PR does / why we need it:
#24975 reports rows on a composite-PK table whose hidden
__mo_cpkey_coldoes not match their own primary-key columns (
serial(pk) != __mo_cpkey_col),which lets a duplicate primary key slip past dedup. The seed is rare
(~15 rows / 3.77M), runtime, and not reproducible by fault injection, so we
cannot locate it by static analysis or after-the-fact scans.
This PR adds an optional, default-off consistency check in the main-table
insert path (
check_null_and_insert_main_table). For composite-PK tables itrecomputes
serial(pk cols)for each row about to be written and compares itto the
__mo_cpkey_colvalue being inserted. On mismatch it reports therecomputed vs stored key, so the corruption is caught at the moment a
misaligned row is written (with the statement/stack context), turning an
unreproducible ghost into a concrete, locatable event.
Controlled by env
MO_DEBUG_CPKEY_ASSERT:log: log an error on mismatch, keep running (safe for canary/long-run)panic: log + panic on mismatch (dumps the stack to locate the producer)Notes:
__mo_cpkey_col).🤖 Generated with Claude Code