-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
txn: Do constraint check when handling repeated acqurie_pessimsitic_lock request #14037
Merged
ti-chi-bot
merged 6 commits into
tikv:master
from
MyonKeminta:m/pessimistic-lock-idempotency-check-existence
Jan 13, 2023
Merged
Changes from 5 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
604ae60
Doconstraint check when handling idempotent pessimsitic lock requests
MyonKeminta ee12f37
Fix warning and format
MyonKeminta c1264a9
Fix lint
MyonKeminta 6cab3d6
Fix lint
MyonKeminta 6824bba
Address comments
MyonKeminta 4d371d0
Merge branch 'master' into m/pessimistic-lock-idempotency-check-exist…
ti-chi-bot File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains 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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a comment about why
locked_with_conflict_ts
cases can be skipped? I cannot think of any problem but I also want to hear how you think about it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be a problem for this case:
Insert
pessimistic locklocked_with_conflict_ts
isSome
and the constraint check is skipped unexpectedlyThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It acquires the lock and lets the client (TiDB) retry the statement in this case. TiDB will find the key already exists when it retries the statement. It's a part of avoiding the key being locked by another transaction when the current transaction does a statement retry, making the retry a waste.
But actually I want to adjust this behavior later: When
should_not_exist
is set and the key exists and the latest version is newer than for_update_ts, return write conflict error evenallow_lock_with_conflict
is set. I think in most cases, when the statement retries, it's likely that it still want to insert the same key and it should still fail.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the current implementation (which I'm planning to adjust later), the retried request in the 4th step will still produce a
locked_with_conflict
result, and TiDB will still retry. It will notice the key already exists when retrying the statement and abort the statement then, at which time the lock will bepessimistic_rollback
-edThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. So the correctness depends on that the returned pessimistic lock result must contain "value existing" information, maybe we could add this in the comment too in case we forget to return the required information?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
Value
field is required inPessimisticLockKeyResult::LockedWithConflict
. I think it's just fine for locked_with_conflict cases? I'm actually not very sure where you prefer to add the comment you saidThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, it's fine.