Skip to content
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

Merged
merged 2 commits into from
Apr 11, 2024

Conversation

ekexium
Copy link
Contributor

@ekexium ekexium commented Apr 9, 2024

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

  • Unit test
  • Integration test
  • Manual test (add detailed scripts or steps below): repeating insert into t select * from t no longer reports resolve lock timeout error. I found it hard to be tested in unit test.
  • No need to test
    • I checked and no code files have been changed.

Side effects

  • Performance regression: Consumes more CPU
  • Performance regression: Consumes more Memory
  • Breaking backward compatibility

Documentation

  • Affects user behaviors
  • Contains syntax changes
  • Contains variable changes
  • Contains experimental features
  • Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

Signed-off-by: ekexium <eke@fastmail.com>
Signed-off-by: ekexium <eke@fastmail.com>
@ti-chi-bot ti-chi-bot bot added release-note-none Denotes a PR that doesn't merit a release note. do-not-merge/needs-triage-completed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Apr 9, 2024
Copy link

tiprow bot commented Apr 9, 2024

Hi @ekexium. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

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.

Copy link

codecov bot commented Apr 9, 2024

Codecov Report

Merging #52461 (22af508) into master (9b78a23) will increase coverage by 2.3451%.
Report is 18 commits behind head on master.
The diff coverage is 100.0000%.

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     
Flag Coverage Δ
integration 51.0341% <100.0000%> (?)
unit 71.0013% <100.0000%> (-0.0670%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components Coverage Δ
dumpling 53.9957% <ø> (ø)
parser ∅ <ø> (∅)
br 49.7484% <ø> (+8.6264%) ⬆️

@ti-chi-bot ti-chi-bot bot added approved needs-1-more-lgtm Indicates a PR needs 1 more LGTM. labels Apr 10, 2024
// 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 {
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@cfzjywxk cfzjywxk Apr 10, 2024

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link

ti-chi-bot bot commented Apr 11, 2024

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ti-chi-bot ti-chi-bot bot added lgtm and removed needs-1-more-lgtm Indicates a PR needs 1 more LGTM. labels Apr 11, 2024
Copy link

ti-chi-bot bot commented Apr 11, 2024

[LGTM Timeline notifier]

Timeline:

  • 2024-04-10 02:40:50.554452641 +0000 UTC m=+1016512.081993187: ☑️ agreed by you06.
  • 2024-04-11 03:39:25.404910199 +0000 UTC m=+1106426.932450740: ☑️ agreed by cfzjywxk.

@ekexium
Copy link
Contributor Author

ekexium commented Apr 11, 2024

/retest

Copy link

tiprow bot commented Apr 11, 2024

@ekexium: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest

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.

@ti-chi-bot ti-chi-bot bot merged commit 5872ccd into pingcap:master Apr 11, 2024
23 of 24 checks passed
3AceShowHand pushed a commit to 3AceShowHand/tidb that referenced this pull request Apr 16, 2024
@ti-chi-bot ti-chi-bot added the needs-cherry-pick-release-8.1 Should cherry pick this PR to release-8.1 branch. label Apr 23, 2024
@ti-chi-bot
Copy link
Member

In response to a cherrypick label: new pull request created to branch release-8.1: #52832.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved lgtm needs-cherry-pick-release-8.1 Should cherry pick this PR to release-8.1 branch. release-note-none Denotes a PR that doesn't merit a release note. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Pipelined DML cannot ignore its own locks when reading
4 participants