Skip to content

pessimistic-transaction: clarify Point Get lock behavior for non-existing keys under different isolation levels (#21740)#21742

Merged
ti-chi-bot[bot] merged 1 commit into
pingcap:masterfrom
ti-chi-bot:cherry-pick-21740-to-master
Jun 25, 2026
Merged

pessimistic-transaction: clarify Point Get lock behavior for non-existing keys under different isolation levels (#21740)#21742
ti-chi-bot[bot] merged 1 commit into
pingcap:masterfrom
ti-chi-bot:cherry-pick-21740-to-master

Conversation

@ti-chi-bot

Copy link
Copy Markdown
Member

This is an automated cherry-pick of #21740

This PR is translated from: pingcap/docs#23111

What is changed, added or deleted? (Required)

Added a Note in the Behaviors section of pessimistic-transaction.md to clarify that the Point Get and Batch Point Get lock behavior for non-existing keys applies only to the REPEATABLE READ isolation level.

Under the READ COMMITTED isolation level, Point Get and Batch Point Get operators do not lock non-existent keys. This is a behavioral difference that can affect applications using SELECT FOR UPDATE for existence checks followed by INSERT.

Which TiDB version(s) do your changes apply to? (Required)

  • master (the latest development version)
  • v9.0 (TiDB 9.0 versions)
  • v8.5 (TiDB 8.5 versions)
  • v8.1 (TiDB 8.1 versions)
  • v7.5 (TiDB 7.5 versions)
  • v7.1 (TiDB 7.1 versions)
  • v6.5 (TiDB 6.5 versions)
  • v6.1 (TiDB 6.1 versions)

What is the related PR or file link(s)?

Do your changes match any of the following descriptions?

  • Delete files
  • Change aliases
  • Need modification after applied to another branch
  • Might cause conflicts after applied to another branch

Verification

This behavior was verified on TiDB v8.5.3:

# Access Method Isolation Level Non-existing Key Lock Acquired?
1 Point Get Repeatable Read id = 999 Yes
2 Point Get Read Committed id = 888 No
3 Batch Point Get Repeatable Read id IN (777, 888) Yes
4 Range Scan Repeatable Read id BETWEEN 100 AND 200 No (no gap lock)

A test script was provided in the PR comments for reviewers to verify the behavior locally.

@ti-chi-bot ti-chi-bot added area/transaction Indicates that the Issue or PR belongs to the area of transaction. lgtm size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. type/cherry-pick-for-master This PR is cherry-picked to master from a source PR. labels Jun 24, 2026
@qiancai

qiancai commented Jun 25, 2026

Copy link
Copy Markdown
Collaborator

/approve

@ti-chi-bot

ti-chi-bot Bot commented Jun 25, 2026

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: qiancai

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

The pull request process is described here

Details 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 the approved label Jun 25, 2026
@ti-chi-bot ti-chi-bot Bot merged commit 71aa21c into pingcap:master Jun 25, 2026
10 checks passed
@ti-chi-bot ti-chi-bot Bot deleted the cherry-pick-21740-to-master branch June 25, 2026 01:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved area/transaction Indicates that the Issue or PR belongs to the area of transaction. lgtm size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. type/cherry-pick-for-master This PR is cherry-picked to master from a source PR.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants