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.

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

Fix the problem that ttlManager may stop working if no need to lock after retry aggressive locking #1522

Merged
merged 4 commits into from
Dec 17, 2024

Conversation

MyonKeminta
Copy link
Contributor

…fter retry aggressive locking

Signed-off-by: MyonKeminta <[email protected]>
@ti-chi-bot ti-chi-bot bot added dco-signoff: yes Indicates the PR's author has signed the dco. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Dec 16, 2024
@MyonKeminta MyonKeminta marked this pull request as draft December 16, 2024 08:26
@ti-chi-bot ti-chi-bot bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Dec 16, 2024
@MyonKeminta MyonKeminta marked this pull request as ready for review December 16, 2024 11:11
@ti-chi-bot ti-chi-bot bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Dec 16, 2024
// acquirePessimisticLock requests, it will call ttlManager.run() again, but it's reentrant and will do nothing
// as the ttlManager is already running.
// * If the primary key is changed, the ttlManager will need to run on the new primary key instead. Reset it.
if !noNewLockToAcquire && !bytes.Equal(txn.aggressiveLockingContext.primaryKey, txn.aggressiveLockingContext.lastPrimaryKey) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe replacing !noNewLockToAcquire with hasNewLockToAcquire is more idiomatic and makes the code more readable

Copy link
Contributor Author

Choose a reason for hiding this comment

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

emmmm, ok

@ti-chi-bot ti-chi-bot bot added needs-1-more-lgtm Indicates a PR needs 1 more LGTM. approved labels Dec 17, 2024
Signed-off-by: MyonKeminta <[email protected]>
Copy link
Contributor

@cfzjywxk cfzjywxk left a comment

Choose a reason for hiding this comment

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

LGTM

@ti-chi-bot ti-chi-bot bot added lgtm and removed needs-1-more-lgtm Indicates a PR needs 1 more LGTM. labels Dec 17, 2024
Copy link

ti-chi-bot bot commented Dec 17, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cfzjywxk, ekexium

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Copy link

ti-chi-bot bot commented Dec 17, 2024

[LGTM Timeline notifier]

Timeline:

  • 2024-12-17 07:57:05.433937389 +0000 UTC m=+943615.522739917: ☑️ agreed by ekexium.
  • 2024-12-17 09:11:54.483845014 +0000 UTC m=+948104.572647556: ☑️ agreed by cfzjywxk.

@ti-chi-bot ti-chi-bot bot merged commit 8e0275c into tikv:master Dec 17, 2024
12 checks passed
@MyonKeminta MyonKeminta deleted the m/fair-locking-ttlmanager-fix branch December 20, 2024 02:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved dco-signoff: yes Indicates the PR's author has signed the dco. lgtm size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants