SELECT LOCK IN SHARE MODE is unsafe

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

See: https://docs.pingcap.com/tidb/stable/pessimistic-transaction#difference-with-mysql-innodb

Under (2) it says that SELECT LOCK IN SHARE MODE is a noop. This seems unsafe, at least by default.

2. What did you expect to see? (Required)

I would like to see it protected by the feature tidb_enable_noop_functions. This will allow users to explicitly turn it on, if they require syntax support but are fine with a noop.

3. What did you see instead (Required)

The statement executes without errors.

4. What is your TiDB version? (Required)

All versions.

[time-and-fate]

/label sig/transaction

This seems similar to #19506 -- I will take a look after it merges.

[sre-bot]

Integrity check:
RCA symptom trigger_condition wa affect_version fix_version fields are empty
@nullnotnil
Please comment /info to get template

[ti-srebot]

Please edit this comment to complete the following information

Bug

1. Root Cause Analysis (RCA)

The syntax SELECT.. LOCK IN SHARE MODE was added to the TiDB parser, but no errors or warnings were added to TiDB when using this syntax. This could lead to a user believing that a shared lock was taken, but no such lock exists in TiDB. In the absence of this feature existing in TiDB, it is important to provide an error to the user so they do not use a shared lock to prevent against modifications.

2. Symptom

When using the syntax SELECT .. LOCK IN SHARE MODE.

3. All Trigger Conditions

see in Minimal reproduce step

4. Workaround (optional)

The user can SELECT .. FOR UPDATE which is supported by TiDB, or as part of the fix for this issue SET tidb_enable_noop_functions = 1.

5. Affected versions

[v4.0.0:v4.0.99]

6. Fixed versions

unplaned