-
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
store/tikv: refactor the ResolveLocks() function for large transaction's implementation #11999
Conversation
…n's implementation After introducing the large transaction, the true lock TTL information is stored in the primary lock, and the TTL may change. This commit updates the resolve lock method, using the new kvproto API
Codecov Report
@@ Coverage Diff @@
## master #11999 +/- ##
===========================================
Coverage 79.9206% 79.9206%
===========================================
Files 461 461
Lines 104087 104087
===========================================
Hits 83187 83187
Misses 14795 14795
Partials 6105 6105 |
PTAL @coocood @lysu @MyonKeminta |
It's actually blocked by tikv/tikv#5390 for integration test. |
tikv/tikv#5390 is ready for reviewing, though I'll add some more test to it |
|
/run-all-tests |
/run-integration-common-test tikv=pr/5390 |
/run-all-tests tikv=pr/5390 |
PTAL @coocood @MyonKeminta |
I find there so many repeated codes like this
and I will clean up them after this PR |
|
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.
The rest LGTM
/run-all-tests tikv=pr/5390 |
/run-all-tests |
@tiancaiamao merge failed. |
/run-integration-common-test |
/run-unit-test |
1 similar comment
/run-unit-test |
That's weird.
|
|
||
if status.ttl > 0 { | ||
// Do not clean lock that is not expired. | ||
continue |
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.
This function need to resolve all locks in locks
. If some of the locks can't be resolved, this function shouldn't return true
.
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.
Then large txn would block GC...
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.
To continue GC anyway, you should resolve all the locks before cleaning up the data. Otherwise not-committed secondaries may miss their primary.
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.
You may remove these locks regardless of their TTL (of course, primary first), but you can never leave these locks there.
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.
We may need to update the CmdGCRequest instead of simply leave the lock here.
@coocood
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.
How will GC's logic be? By the way, GC Request is not used by default now.
…n's implementation (pingcap#11999) After introducing the large transaction, the true lock TTL information is stored in the primary lock, and the TTL may change. This commit updates the resolve lock method, using the new kvproto CheckTxnStatus API
What problem does this PR solve?
After introducing the large transaction, the true lock TTL information is stored in the primary lock, and the TTL may change.
This commit updates the resolve lock method, using the new kvproto API.
What is changed and how it works?
Tiny refactor to adapt the new kvproto API.
Blocked by #11974 which implements theCheckTxnStatus
API, please review that one first.Check List
Tests