-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
tikv: check lock timeout again after resolving lock #14066
Conversation
Signed-off-by: Yilin Chen <[email protected]>
Codecov Report
@@ Coverage Diff @@
## master #14066 +/- ##
================================================
- Coverage 80.6472% 80.1568% -0.4904%
================================================
Files 488 483 -5
Lines 124659 121150 -3509
================================================
- Hits 100534 97110 -3424
+ Misses 16373 16296 -77
+ Partials 7752 7744 -8 |
@@ -750,33 +750,49 @@ func (action actionPessimisticLock) handleSingleBatch(c *twoPhaseCommitter, bo * | |||
// if the lock left behind whose related txn is already committed or rollbacked, | |||
// (eg secondary locks not committed or rollbacked yet) | |||
// we cant return "nowait conflict" directly | |||
if lock.LockType == pb.Op_PessimisticLock { |
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.
Why remove this check?
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.
I don't think the check is necessary. Blocking by an optimistic lock is possible with large transaction. (Or am I forgetting something...?)
Signed-off-by: Yilin Chen <[email protected]>
// Heartbeats will increase the TTL of the primary key | ||
|
||
// wait until secondary key exceeds its own TTL | ||
time.Sleep(time.Duration(ManagedLockTTL) * time.Millisecond) |
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.
Sleep 20s in the test?
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 tests it's 3 seconds. I guess it's acceptable?
Signed-off-by: Yilin Chen <[email protected]>
LGTM |
@sticnarf |
Signed-off-by: Yilin Chen <[email protected]>
I've removed the check before resolve lock. PTAL @coocood @tiancaiamao |
LGTM |
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.
LGTM
/merge |
/run-all-tests |
cherry pick to release-3.0 failed |
Signed-off-by: Yilin Chen <[email protected]>
Signed-off-by: Yilin Chen [email protected]
What problem does this PR solve?
Fix #14063
What is changed and how it works?
Before resolving locks, we checked whether the locks are expired according to its own TTL. However, it's not accurate because heartbeat only updates the TTL of the primary key.
So we still fetch
msBeforeTxnExpired
fromResolveLocks
. IfmsBeforeTxnExpired
is not zero, it means there are still locks blocking us acquiring the pessimistic lock. We should return timeout error if necessary.Check List
Tests
Code changes
Side effects
Related changes
Release note