executor: pessimistic lock on the temporary table should not be written to TiKV

[tiancaiamao]

What problem does this PR solve?

Avoid any kind of (pessimistic) lock on the temporary table been written to TiKV

Problem Summary:

What is changed and how it works?

The concept of "lock" is complex.

1. select ... for update

Basically, it means lock for the read operation.
We use MVCC and the transaction isolation level is actually "snapshot isolation", there are locks for the write operation but no locks for the read operation.
"write skew" is problem in "snapshot isolation". To overcome it, we provide "select ... for update" which also lock for read and can be used to fix the "write skew" problem.

2. pessimistic / optimistic

From TiDB 3.0, we start to support the pessimistic transaction mode.
Pessimistic transaction differs from the optimistic transaction that it write locks to the TiKV immediately, instead of caching the changes in memory and write to TiKV until commit.

3. (batch) point get / coprocessor

(batch) point get is a special code path for performance optimization.
With two different implementation, we have to take special care to maintain the different code path.
And for the pessimistic transaction, there are some minor behaviour differences between point get / non-point get request.

Under any circumstance, operations on the temporary table should not write locks to the TiKV.

In #24540 we cover the point get and batch point get.
However, there are 2*2*2 = 8 combinations in total, to cover them all, I chose the common code path.

What's Changed:

Filter out the keys belong to the temporary table in doLockKeys(), all the pessimistic mode lock goes through this code path.

How it Works:

All the optimistic mode lock should have already been filtered before the 2PC commit in PR #24196.

So all the cases are covered after this PR.

Check List

Tests

• Unit test

Release note

• No release note

[coocood]

can we revert #24540 now?

[tiancaiamao]

can we revert #24540 now?

I think that would hurt our contributor's feeling or at least discourage their enthusiasm for contribution.
#24540 is not introducing a bug or something wrong, it's just not solve all the cases in one PR. @coocood

[coocood]

can we revert #24540 now?

I think that would hurt our contributor's feeling or at least discourage their enthusiasm for contribution.
#24540 is not introducing a bug or something wrong, it's just not solve all the cases in one PR. @coocood

Or just remove the code that doing duplicated calculation to save CPU?

[tiancaiamao]

#24540 is reverted, PTAL @coocood

[tiancaiamao]

/run-check_dev
/run-check_dev_2

[coocood]

/lgtm

[lysu]

/lgtm

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• coocood
• lysu

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by writing /lgtm in a comment.
Reviewer can cancel approval by writing /lgtm cancel in a comment.

[lysu]

/merge

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: 6364a82

[ti-chi-bot]

@tiancaiamao: Your PR was out of date, I have automatically updated it for you.

At the same time I will also trigger all tests for you:

/run-all-tests

If the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes.

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 ti-community-infra/tichi repository.