Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

txn: incompatbile lock behaviour for cop and point get for update read #54705

Open
cfzjywxk opened this issue Jul 18, 2024 · 0 comments · May be fixed by #54773
Open

txn: incompatbile lock behaviour for cop and point get for update read #54705

cfzjywxk opened this issue Jul 18, 2024 · 0 comments · May be fixed by #54773

Comments

@cfzjywxk
Copy link
Contributor

cfzjywxk commented Jul 18, 2024

Bug Report

Please answer these questions before submitting your issue. Thanks!

When select for update is executed outside explicit transactions, there would be SelectLockExec for coprocessor read queries but no lock for point get queries, the behaviours are in-consistent.

1. Minimal reproduce step (Required)

create table t(a int key);
explain select * from t for update;
explain select * from t where a = 1 for update;

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

Both select would not have lock operations.

3. What did you see instead (Required)

There is SelectLockExec on select * from t for update;

explain select * from t for update;
+-------------------------+----------+-----------+---------------+--------------------------------+
| id                      | estRows  | task      | access object | operator info                  |
+-------------------------+----------+-----------+---------------+--------------------------------+
| SelectLock_5            | 10000.00 | root      |               | for update 0                   |
| └─TableReader_7         | 10000.00 | root      |               | data:TableFullScan_6           |
|   └─TableFullScan_6     | 10000.00 | cop[tikv] | table:t       | keep order:false, stats:pseudo |
+-------------------------+----------+-----------+---------------+--------------------------------+
3 rows in set (0.001 sec)

While the point get query dose not have lock flag

MySQL [test]> explain select * from t where a = 1 for update;
+-------------+---------+------+---------------+---------------+
| id          | estRows | task | access object | operator info |
+-------------+---------+------+---------------+---------------+
| Point_Get_1 | 1.00    | root | table:t       | handle:1      |
+-------------+---------+------+---------------+---------------+

Note though the SelectLockExec is generated in the SQL plan, it would be skipped when building SelectLockExec executor at https://github.com/pingcap/tidb/blob/master/pkg/executor/builder.go#L770.

4. What is your TiDB version? (Required)

Nightly 26378cb

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants