-
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
cop: ignore locks with the same start_ts #52461
Conversation
Signed-off-by: ekexium <eke@fastmail.com>
Signed-off-by: ekexium <eke@fastmail.com>
Hi @ekexium. Thanks for your PR. PRs from untrusted users cannot be marked as trusted with I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #52461 +/- ##
================================================
+ Coverage 72.1802% 74.5253% +2.3451%
================================================
Files 1467 1492 +25
Lines 426855 441891 +15036
================================================
+ Hits 308105 329321 +21216
+ Misses 99560 92000 -7560
- Partials 19190 20570 +1380
Flags with carried forward coverage won't be shown. Click here to find out more.
|
// the start_ts could conflict with another pipelined-txn's start_ts. | ||
// in which case the locks of same ts cannot be ignored. | ||
// We rely on the assumption: start_ts is not from PD => this is a stale read. | ||
if !req.IsStaleness { |
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.
For tidb_snapshot
read path, the staleness
may not be set.
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 is a bit confusing. Is it intentional or an oversight? I suppose that tidb_snapshot
is solely used for stale reads.
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 stale
flag is not set in the kv request for tidb_snapshot
if I do not remember wrong, there are two stale read implementaions in tidb and tidb_snasphot
is the earlier one.
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.
Yes I've verified that. I mean if it's unintentional we can fix it by setting IsStaleness
for this case.
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.
Do you mean setting IsStaleness
for tidb_snaoshot
read?
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.
Yes
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 theory, this is the way to proceed with the change.
However, it's a breaking change because tidb_snapshot
wasn't set before (setting it will trigger a check on safe_ts
). Currently, it's unclear if other components rely on this behavior.
We can proceed by merging this PR first.
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 it's possible that when tidb_snapshot
is set to a ts conflicting with a pipelined txn, coprocessor ignores the locks while point_get doens't?
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 think so though tidb_snapshot
seems not to be used widely currenly.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cfzjywxk, you06 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 |
/retest |
@ekexium: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
In response to a cherrypick label: new pull request created to branch |
What problem does this PR solve?
Issue Number: close #52460
Problem Summary:
What changed and how does it work?
If this cop is not a stale read, which means its start_ts is fetched from PD, which means the start_ts cannot conflict with other transactions, add this ts to resolved_locks so that in a pipelined txn the locks belonging to the same txn will not block coprocessor.
For get and batch_get, they already put start_ts in resolved_locks.
Check List
Tests
insert into t select * from t
no longer reportsresolve lock timeout
error. I found it hard to be tested in unit test.Side effects
Documentation
Release note
Please refer to Release Notes Language Style Guide to write a quality release note.