db/state: unify commitment-branch referencing predicate#20944
Merged
Conversation
ValuesPlainKeyReferencingThresholdReached was a parity check
((span)%2 == 0) and MayContainValuesPlainKeyReferencing was a strict-
greater size check (span > 2). Under the old merge planner spans were
always {1, 2, 4, 8, ...}, so the parity test was effectively "merged
file?" — but with clipMergeStartToFileBoundary the planner can now emit
odd spans >= 3, which the parity test misclassifies as plain and the
read path then fails to dereference. The two predicates also disagreed
at span = 2: the write path shortened those files but the integrity
check skipped them.
Replace both bodies with span >= minStepsForReferencing (= 2), matching
the constant's name, and drop MayContainValuesPlainKeyReferencing in
favor of the surviving function. Span-1 files (the only legitimate
plain case) are unchanged; every multi-step file is now consistently
treated as referencing on read, write, and integrity paths.
awskii
approved these changes
May 3, 2026
Member
|
spotted same thing |
This was referenced May 4, 2026
AskAlexSharov
changed the title
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.
This PR fixes some logic re: handling shortened keys in commitment files:
ValuesPlainKeyReferencingThresholdReachedas a general rule, if file contains 1 step, then use plain keys, otherwise references. This works well currently because all merged files contains even number of steps (2, 4, 8, 16, 32, etc.).The problem is the logic uses %0 implying odd number of steps in range should contain plain keys as well. Because I'm modifying the step-rebase command to allow arbitrary number of steps inside a merged range, if you convert an existing node and it ends up containing an odd number of steps, it'll crash on next merge.
MayContainValuesPlainKeyReferencing, which kind of does the formula correctly, but it misses files with 2 steps. That function is used only by integrity checks, it is currently missing 2-step files and it is IMO incorrect. I'm removing that almost-duplicate function and retrofitting all callers to useValuesPlainKeyReferencingThresholdReached.