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

[ti-chi-bot]

This is an automated cherry-pick of #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)?

• Related documentation: https://docs.pingcap.com/tidbcloud/pessimistic-transaction/#behaviors

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.

[gemini-code-assist]

Code Review

This pull request updates the pessimistic transactions documentation to clarify that Point Get and Batch Point Get operators do not lock non-existent keys under the Read Committed isolation level. The review feedback suggests a minor improvement to avoid repeating the operator names in consecutive sentences, enhancing readability in accordance with the style guide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[qiancai]

/approve

[ti-chi-bot]

[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:

• OWNERS [qiancai]

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