Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

release-23.1: storage: fix a series of intent resolution bugs with ignored seq nums #117644

Merged
merged 3 commits into from
Jan 11, 2024
Merged

release-23.1: storage: fix a series of intent resolution bugs with ignored seq nums #117644

merged 3 commits into from
Jan 11, 2024

Conversation

miraradeva
Copy link
Contributor

@miraradeva miraradeva commented Jan 10, 2024 •
edited
Loading

Backport 3/3 commits from #117541.

/cc @cockroachdb/release

Previously, the logic in mvccResolveWriteIntent was structured in such a
way that if an intent contained both ignored and non-ignored seq nums
in its intent history, the intent may end up being updated instead of
aborted or unmodified (see examples in 644be59).

This commit fixes the bugs by ensuring that the intent history is
modified only when an intent resolution update is not aborted, and the
update and the actual intent have the same epoch.

Fixes: #117553

Release note: None

Release justification: Fixes an unexpected behavior in intent resolution.

@miraradeva
storage: rename intent to update in MVCC intent resolution functions
ac51062 
Rename the intent argument to the mvccResolveWriteIntent,
MVCCResolveWriteIntent, and MVCCResolveWriteIntentRange functions to
make it clear that it refers to the state passed in via ResolveIntent,
and not the current value of the stored intent.

Informs: cockroachdb#117553

Release note: None
@miraradeva
storage: repro a series of intent resolution bugs with ignored seq nums
644be59 
The logic in mvccResolveWriteIntent is structured in such a way that if
an intent contains both ignored and non-ignored seq nums in its intent
history, the intent may end up being updated instead of aborted or
unmodified. For the following examples, assume the intent has a
history ["a", "b"] where "a" is written first, and "b" is ignored.

1. The intent resolution has status aborted. Instead of aborting the
intent, it is modified to have value "a" and an empty intent history.

2. The intent resolution has status pending, and the intent has a lower
epoch than the resolution. The intent should be aborted because the new
epoch may not write it again. Instead, it is updated with value "a" and
an empty intent history.

3. Same as 2 but the intent resolution has status committed.

4. The intent resolution has status pending, the intent is not pushed
and has a higher epoch than the resolution. The intent should not be
updated because the intent history is updated only when the epochs
match. Instead, it is updated with value "a" and an empty intent
history.

5. Same as 4 but the intent is pushed. The intent should be updated to
bump its timestamp in order to unblock the pusher. The intent history
should not be updated for the same reason as in 3. Instead, the intent
is updated with value "a" and an empty intent history.

This commit only reproduces the bugs.

Informs: cockroachdb#117553

Release note: None
@miraradeva
storage: fix a series of intent resolution bugs with ignored seq nums
0a3085d 
Previously, the logic in mvccResolveWriteIntent was structured in such a
way that if an intent contained both ignored and non-ignored seq nums
in its intent history, the intent may end up being updated instead of
aborted or unmodified (see examples in 540efac).

This commit fixes the bugs by ensuring that the intent history is
modified only when an intent resolution update is not aborted, and the
update and the actual intent have the same epoch.

Fixes: cockroachdb#117553

Release note: None
@miraradeva miraradeva requested a review from a team as a code owner January 10, 2024 21:07
@blathers-crl blathers[crl]
Copy link

blathers-crl bot commented Jan 10, 2024

Thanks for opening a backport.

Please check the backport criteria before merging:

  • Backports should only be created for serious
    issues     or test-only changes.
  • Backports should not break backwards-compatibility.
  • Backports should change as little code as possible.
  • Backports should not change on-disk formats or node communication protocols.
  • Backports should not add new functionality (except as defined
    here).
  • Backports must not add, edit, or otherwise modify cluster versions; or add version gates.
  • All backports must be reviewed by the owning areas TL and one additional
    TL. For more information as to how that review should be conducted, please consult the backport
    policy    .
If your backport adds new functionality, please ensure that the following additional criteria are satisfied:
  • There is a high priority need for the functionality that cannot wait until the next release and is difficult to address in another way.
  • The new functionality is additive-only and only runs for clusters which have specifically “opted in” to it (e.g. by a cluster setting).
  • New code is protected by a conditional check that is trivial to verify and ensures that it only runs for opt-in clusters. State changes must be further protected such that nodes running old binaries will not be negatively impacted by the new state (with a mixed version test added).
  • The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.
  • Your backport must be accompanied by a post to the appropriate Slack
    channel (#db-backports-point-releases or #db-backports-XX-X-release) for awareness and discussion.

Also, please add a brief release justification to the body of your PR to justify this
backport.

@blathers-crl blathers-crl bot added the backport Label PR's that are backports to older release branches label Jan 10, 2024
@cockroach-teamcity
Copy link
Member

This change is Reviewable

@miraradeva
Copy link
Contributor Author

This change has a slight modification compared to the original PR in #117541. In this PR, the data driven unit tests don't assert on the logged logical ops because that feature of TestMVCCHistories is not available in 23.1.

nvanbenschoten
nvanbenschoten approved these changes Jan 11, 2024
View reviewed changes
Copy link
Member

@nvanbenschoten nvanbenschoten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewed 1 of 1 files at r1, 4 of 4 files at r2, 4 of 4 files at r3, all commit messages.
Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @RaduBerinde)

@miraradeva miraradeva merged commit cd1de07 into cockroachdb:release-23.1 Jan 11, 2024
6 checks passed
jbowens
jbowens reviewed Jan 11, 2024
View reviewed changes
Copy link
Collaborator

@jbowens jbowens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jbowens jbowens jbowens left review comments

@nvanbenschoten nvanbenschoten nvanbenschoten approved these changes

@RaduBerinde RaduBerinde Awaiting requested review from RaduBerinde RaduBerinde is a code owner automatically assigned from cockroachdb/storage

Assignees
No one assigned
Labels
backport Label PR's that are backports to older release branches
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@miraradeva @cockroach-teamcity @jbowens @nvanbenschoten