cop: ignore locks with the same start_ts #52461
Conversation
Signed-off-by: ekexium <eke@fastmail.com>
Signed-off-by: ekexium <eke@fastmail.com>
ti-chi-bot
bot
added
release-note-none
do-not-merge/needs-triage-completed
size/S
|
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.
For tidb_snapshot read path, the staleness may not be set.
There was a problem hiding this comment.
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.
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.
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.
Do you mean setting IsStaleness for tidb_snaoshot read?
There was a problem hiding this comment.
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.
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.
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 tno longer reportsresolve lock timeouterror. 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.