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.2: kv: fix handling of non-txn'al locking requests and recompute wait queues when locking requests drop out #114023

Merged
merged 2 commits into from
Nov 8, 2023
Merged

release-23.2: kv: fix handling of non-txn'al locking requests and recompute wait queues when locking requests drop out #114023

merged 2 commits into from
Nov 8, 2023

Conversation

arulajmani
Copy link
Collaborator

Backport:

Please see individual PRs for details.

/cc @cockroachdb/release

@arulajmani
concurrency: recompute wait queues when locking requests drop out
a2509b8 
A locking request must actively wait in a lock's wait queues if:
- it conflicts with any of the lock holders.
- or it conflicts with a lower sequence numbered request already in
the lock's wait queue.

As a result, if a locking request exits a lock's wait queue without
actually acquiring the lock, it may allow other locking requests to
proceed. This patch recomputes wait queues whenever a locking request
exits a lock's wait queues to detect such scenarios and unblock requests
which were actively waiting previously not no longer need to.

Fixes cockroachdb#111144

Release note: None
@arulajmani
kv: fix handling of non-txn'al locking requests in recomputeWaitQueues
bbd9f3f 
If a lock is not held, a non-transactional locking request should never
be at the head of the queuedLockingRequests wait queue. That would make
it hold a claim on the lock, which is something non-transactional
requests are not allowed to do.

Previously, a call to `recomputeWaitQueues` could end up leaving the
queuedLockingRequests wait queue in such a state in some rare cases.
That's because we would only consider removing a non-transactional
request from the wait queue if it was actively waiting. It turns out
we want to indiscriminately remove non-transactional requests from the
wait queue if they don't conflict with the claim holder.

Closes cockroachdb#113924
Closes cockroachdb#113985

Release note: None
@arulajmani arulajmani requested a review from a team as a code owner November 8, 2023 14:45
@blathers-crl blathers[crl]
Copy link

blathers-crl bot commented Nov 8, 2023

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 Nov 8, 2023
@cockroach-teamcity
Copy link
Member

This change is Reviewable

nvanbenschoten
nvanbenschoten approved these changes Nov 8, 2023
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 2 of 2 files at r1, 2 of 2 files at r2, all commit messages.
Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @arulajmani)

@arulajmani arulajmani merged commit ac9dcb7 into cockroachdb:release-23.2 Nov 8, 2023
1 of 2 checks passed
@arulajmani arulajmani mentioned this pull request Nov 8, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@nvanbenschoten nvanbenschoten nvanbenschoten approved these changes

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.
3 participants
@arulajmani @cockroach-teamcity @nvanbenschoten