*: pessimistic lock doesn't work on the partition for subquery/joins

[bb7133]

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

create table t (c_int int, d_int int, primary key (c_int), key(d_int)) partition by hash (c_int) partitions 4 ;
insert into t values (1, 2);

(session 1)
begin pessimistic;
select * from t where d_int in (select d_int from t where c_int = 1) for update;

(session 2)
begin pessimistic;
select * from t where d_int = 2 for update;

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

Session 1 and session 2 tries to acquire the lock for the same record, so one of them should be blocked and waited for the lock.

3. What did you see instead (Required)

Neither select ... for update is blocked.

4. What is your TiDB version? (Required)

I reproduced this bug in the latest master, but it should be reproduced in all existing releases that support pessimistic lock and (hash?) partitions.

5. Additional information

This bug is actually found when @blacktear23 trying to solve #21509, both of the bugs are caused by the same reason. You can check #21509 for more details.

[cfzjywxk]

@bb7133
Could the fix pr merged before 5.0 GA, or is there any risk to merge the fix?

[blacktear23]

@bb7133
Could the fix pr merged before 5.0 GA, or is there any risk to merge the fix?

#21148
@cfzjywxk PTAL

[qw4990]

This issue can be solved by #21148.

[ti-srebot]

Please edit this comment or add a new comment to complete the following information

Not a bug

1. Remove the 'type/bug' label
2. Add notes to indicate why it is not a bug

Duplicate bug

1. Add the 'type/duplicate' label
2. Add the link to the original bug

Bug

Note: Make Sure that 'component', and 'severity' labels are added
Example for how to fill out the template: #20100

1. Root Cause Analysis (RCA) (optional)

2. Symptom (optional)

3. All Trigger Conditions (optional)

4. Workaround (optional)

5. Affected versions

6. Fixed versions