ddl: fix ExistsTableRow and add tests for skip reorg checks #57778

tangenta · 2024-11-28T03:05:33Z

What problem does this PR solve?

Issue Number: close #57769

Problem Summary:

The cause is the PR(https://github.com/pingcap/tidb/pull/56406/files#diff-45ad039a8b87835b475a52615355c444538d3a1f31a84d7b3ac94e15b1ce8721R1159), which uses the user specified timestamp math.MaxInt64 to read directly with DAG interfaces.

What changed and how does it work?

Use the transaction key-value interface instead to check if a table is empty.

Check List

Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)
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

Release note

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

None

tiprow · 2024-11-28T03:05:50Z

Hi @tangenta. 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-sigs/prow repository.

cfzjywxk · 2024-11-28T03:27:33Z

pkg/ddl/reorg.go

-	err = result.Next(ctx.ddlJobCtx, chk)
+func existsTableRow(ctx *ReorgContext, store kv.Storage, tbl table.PhysicalTable) (bool, error) {
+	found := false
+	err := iterateSnapshotKeys(ctx, store, kv.PriorityLow, tbl.RecordPrefix(), math.MaxUint64, nil, nil,


A safer way is to fetch and use a ts from pd like pdCli.GetTS(ctx). math.MaxUint64 cannot provide snapshot semantics.

I think we don't need snapshot semantics here. This function determines if we can use the fast path for data reorganization:

if it returns false, but actually it is true, we won't enter the fast path

if it returns true, but actually it is false, we enter the fast path, and the following insertions will be handled by dual-write mechanism (txn mode) or temp-index-merge mechanism (ingest mode). This is covered by test https://github.com/pingcap/tidb/pull/57778/files#diff-2998ac87ef4adb20bfc6bf8ce58ace7015800e57f330bacad08cba4b90350300R908

Another layer of semantics for safety is that, in the transaction layer and TiKV, the use of math.MaxUint64 is only expected for primary key point-get autocommit reads. Other scenarios should not use math.MaxUint64 for reads. It's better to stick to PD-allocated timestamps instead.

I think we don't need snapshot semantics here.

Did you mean that you don't need a consistent snapshot, so you try to use a weaker or looser way for the reading?

I think reading with MaxUint64 seems to be much more special than you, as well as many other developers, might think. At least it is so after implementing async commit. Maybe it's better if you only consider whether the overhead of getting a new ts from PD is so unacceptable to you.

reading with MaxUint64 seems to be much more special

can you give more detail? or some doc link?

the use of math.MaxUint64 is only expected for primary key point-get autocommit reads. Other scenarios should not use math.MaxUint64 for reads

In my understanding, snapshot reading is not a pure "reading" at TiKV. It updates the Max TS so caused side effect to async commit. #57769 https://cn.pingcap.com/blog/async-commit-principle/

In my understand, snapshot reading is not a pure "reading" at TiKV. It has side effect to async commit. #57769

that's too bad, a read operation corrupt the entire cluster

can you give more detail? or some doc link?

There's not any document dedicated to talking about this as far as I know. There's many special handling for reading with MaxUint64. For example, TiKV skipping updating the max_ts using it; special lock-ignoring logic when checking read-write conflict; etc. It also used to cause difficulty for us in developent or optimization work.

snapshot reading is not a pure "reading" at TiKV.

The max_ts in async commit / 1PC is an approach to let writing transactions to avoid affecting other reading operations. It tells the latest timestamp allocated by PD that has been used on this TiKV node. It's quite doubtful to me whether this can be the reason to say that the reading is not "pure".

that's too bad

The design is based on the fact that the reads and writes are strongly ordered by PD's globally unique and monotonic TSO allocation, and writing cannot change the snapshot has been read, otherwise the snapshot becomes not repeat-readable, then it's no longer a snapshot. You may think that this makes async commit transactions committed to an incorrect future version and cause its result not readable, and things would be all better if async commit not exists. But that's the choice that async commit transactions made to avoid breaking your snapshot. If the transaction is committed in 2PC mode which is not related to the max_ts mechanism, there's still another form of corruption, that is, your snapshot is changed and becomes not repeat-readable. If you believe there's something bad, I think the bad part is that the strong ordering that's supposed to be provided by TSO is broken.

for bad, i mean a read only operation has side effects, and it corrupt the entire cluster

read only operation shouldn't have such effects as a common design practice AFAIK

codecov · 2024-11-28T03:29:50Z

Codecov Report

Attention: Patch coverage is 80.00000% with 8 lines in your changes missing coverage. Please review.

Project coverage is 74.8316%. Comparing base (ca395fa) to head (8971173).
Report is 11 commits behind head on master.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #57778        +/-   ##
================================================
+ Coverage   72.8370%   74.8316%   +1.9945%     
================================================
  Files          1677       1722        +45     
  Lines        464191     474115      +9924     
================================================
+ Hits         338103     354788     +16685     
+ Misses       105210      97131      -8079     
- Partials      20878      22196      +1318

Flag	Coverage Δ
integration	`49.4612% <75.0000%> (?)`
unit	`72.2663% <80.0000%> (+0.0405%)`	⬆️

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

Components	Coverage Δ
dumpling	`52.7673% <ø> (ø)`
parser	`∅ <ø> (∅)`
br	`61.2056% <ø> (+15.5261%)`	⬆️

D3Hunter

rest lgtm except existing comments

pkg/ddl/tests/indexmerge/merge_test.go

ti-chi-bot · 2024-11-28T07:58:37Z

[LGTM Timeline notifier]

Timeline:

2024-11-28 03:34:50.710258398 +0000 UTC m=+693878.329912909: ☑️ agreed by crazycs520.
2024-11-28 07:58:35.707009534 +0000 UTC m=+709703.326664050: ☑️ agreed by MyonKeminta.

ti-chi-bot · 2024-11-28T08:32:16Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: crazycs520, D3Hunter, MyonKeminta

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:

~~pkg/ddl/OWNERS~~ [D3Hunter]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

tangenta · 2024-11-28T08:33:24Z

/retest

tiprow · 2024-11-28T08:33:45Z

@tangenta: 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-sigs/prow repository.

ti-chi-bot · 2024-11-28T11:34:49Z

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

…57801) close #57769

tangenta added 2 commits November 28, 2024 10:58

ddl: fix ExistsTableRow and add tests for skip reorg checks

372bfbf

refine code

177bcd4

ti-chi-bot bot added release-note-none Denotes a PR that doesn't merit a release note. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Nov 28, 2024

refine test

788fc1b

tangenta added the needs-cherry-pick-release-8.5 Should cherry pick this PR to release-8.5 branch. label Nov 28, 2024

tangenta requested review from lance6716 and D3Hunter November 28, 2024 03:10

cfzjywxk reviewed Nov 28, 2024

View reviewed changes

D3Hunter reviewed Nov 28, 2024

View reviewed changes

pkg/ddl/tests/indexmerge/merge_test.go Outdated Show resolved Hide resolved

crazycs520 approved these changes Nov 28, 2024

View reviewed changes

ti-chi-bot bot added the needs-1-more-lgtm Indicates a PR needs 1 more LGTM. label Nov 28, 2024

tangenta added 4 commits November 28, 2024 11:46

fix linter and address comment

c10bab4

address comment

d0d0d85

update bazel

c81fe1f

prevent using MaxUint64

8971173

MyonKeminta approved these changes Nov 28, 2024

View reviewed changes

ti-chi-bot bot added lgtm and removed needs-1-more-lgtm Indicates a PR needs 1 more LGTM. labels Nov 28, 2024

D3Hunter approved these changes Nov 28, 2024

View reviewed changes

ti-chi-bot bot added the approved label Nov 28, 2024

ti-chi-bot bot merged commit b114219 into pingcap:master Nov 28, 2024
27 checks passed

ti-chi-bot mentioned this pull request Nov 28, 2024

ddl: fix ExistsTableRow and add tests for skip reorg checks (#57778) #57801

Merged

13 tasks

ti-chi-bot bot pushed a commit that referenced this pull request Nov 29, 2024

ddl: fix ExistsTableRow and add tests for skip reorg checks (#57778) (#…

43b21d4

…57801) close #57769

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ddl: fix ExistsTableRow and add tests for skip reorg checks #57778

ddl: fix ExistsTableRow and add tests for skip reorg checks #57778

tangenta commented Nov 28, 2024

tiprow bot commented Nov 28, 2024

cfzjywxk Nov 28, 2024

tangenta Nov 28, 2024

cfzjywxk Nov 28, 2024

MyonKeminta Nov 28, 2024 •

edited

Loading

D3Hunter Nov 28, 2024

lance6716 Nov 28, 2024 •

edited

Loading

D3Hunter Nov 28, 2024

MyonKeminta Nov 28, 2024

D3Hunter Nov 28, 2024

codecov bot commented Nov 28, 2024 •

edited

Loading

D3Hunter left a comment

ti-chi-bot bot commented Nov 28, 2024

ti-chi-bot bot commented Nov 28, 2024

tangenta commented Nov 28, 2024

tiprow bot commented Nov 28, 2024

ti-chi-bot commented Nov 28, 2024

ddl: fix ExistsTableRow and add tests for skip reorg checks #57778

ddl: fix ExistsTableRow and add tests for skip reorg checks #57778

Conversation

tangenta commented Nov 28, 2024

What problem does this PR solve?

What changed and how does it work?

Check List

Release note

tiprow bot commented Nov 28, 2024

cfzjywxk Nov 28, 2024

Choose a reason for hiding this comment

tangenta Nov 28, 2024

Choose a reason for hiding this comment

cfzjywxk Nov 28, 2024

Choose a reason for hiding this comment

MyonKeminta Nov 28, 2024 • edited Loading

Choose a reason for hiding this comment

D3Hunter Nov 28, 2024

Choose a reason for hiding this comment

lance6716 Nov 28, 2024 • edited Loading

Choose a reason for hiding this comment

D3Hunter Nov 28, 2024

Choose a reason for hiding this comment

MyonKeminta Nov 28, 2024

Choose a reason for hiding this comment

D3Hunter Nov 28, 2024

Choose a reason for hiding this comment

codecov bot commented Nov 28, 2024 • edited Loading

Codecov Report

D3Hunter left a comment

Choose a reason for hiding this comment

ti-chi-bot bot commented Nov 28, 2024

[LGTM Timeline notifier]

ti-chi-bot bot commented Nov 28, 2024

tangenta commented Nov 28, 2024

tiprow bot commented Nov 28, 2024

ti-chi-bot commented Nov 28, 2024

MyonKeminta Nov 28, 2024 •

edited

Loading

lance6716 Nov 28, 2024 •

edited

Loading

codecov bot commented Nov 28, 2024 •

edited

Loading