txn: unexpected behavior for point-get and LOCK IN SHARE MODE

[bb7133]

Bug Report

1. Minimal reproduce step (Required)

Using LOCK IN SHARED MODE in a point-get query:

set @@tidb_enable_noop_functions='OFF';
create table t(a int key, b int);
insert into t values (1, 1), (2, 2);
select * from t where a=1 lock in share mode;
select * from t where b=1 lock in share mode;

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

According to TiDB document, TiDB should report an error using SHARE IN LOCK MODE when tidb_enable_noop_functions=OFF.

3. What did you see instead (Required)

tidb> select * from t where a=1 lock in share mode;
+---+------+
| a | b    |
+---+------+
| 1 |    1 |
+---+------+
1 row in set (5.80 sec)

tidb> select * from t where b=1 lock in share mode;
ERROR 1235 (42000): function LOCK IN SHARE MODE has only noop implementation in tidb now, use tidb_enable_noop_functions to enable these functions

4. What is your TiDB version? (Required)

All versions of TiDB have this issue, I believe.

5. Root cause analysis

Notice that for select * from t where a=1 lock in share mode, TiDB uses a 'fast path' for point-get, we didn't handle LOCK IN SHARE MODE in this path.

[henrybw]

/assign

[bb7133]

Hi @henrybw, thanks for picking this issue!

Notice that for select * from t where a=1 lock in share mode, TiDB uses a 'fast path' for point-get, we didn't handle LOCK IN SHARE MODE in this path.

For some further info useful for your commit:

For 'non fast path', you could find the checking for LockMode in: logical_plan_builder.go#L4189-L4210

Then for 'fast path', the checking for 'lock clause' is in point_get_plan.go#L867-L903, and I believe that we should update codes here to achieve similar logic.