Inconsistent lock behavior on partitioned and non-partitioned tables
- Dominant language
- Go
- Stars
- 40.5k
- Forks
- 6.2k
- PR merge metrics
- PR metrics pending
Description
## Bug Report
Please answer these questions before submitting your issue. Thanks!
### 1. Minimal reproduce step (Required)
```sql
create table t0(c0 bool zerofill default false , primary key(c0)) partition by range(c0) (partition p0 values less than (1000), partition p1 values less than (7415), partition p2 values less than (14307), partition p3 values less than (maxvalue));
insert into t0(c0) values (true), (false);
CREATE TABLE t0_oracle LIKE t0;
alter table t0_oracle remove partitioning;
INSERT INTO t0_oracle SELECT * FROM t0;
session 0: SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
session 0: START TRANSACTION WITH CAUSAL CONSISTENCY ONLY;
session 0: REPLACE INTO t0 VALUES (false);
session 1: UPDATE t0 SET c0 = c0 + 19 WHERE ((((t0.c0)=('')))OR(((t0.c0)>=(-1598653439)))); -- no lock wait
session 0: START TRANSACTION WITH CAUSAL CONSISTENCY ONLY;
session 0: REPLACE INTO t0_oracle VALUES (false);
session 1: UPDATE t0_oracle SET c0 = c0 + 19 WHERE ((((t0_oracle.c0)=('')))OR(((t0_oracle.c0)>=(-1598653439)))); -- encounter lock wait
```
### 2. What did you expect to see? (Required)
on partitioned table, the result of REPLACE is:
```sql
mysql> REPLACE INTO t0 VALUES (false);
Query OK, 1 row affected (0.00 sec)
```
That means it do affected a line, but UPDATE on session 1 didn't encounter lock wait, which is inconsistent with non-partitioned table.
### 3. What did you see instead (Required)
consistent lock bahavior
### 4. What is your TiDB version? (Required)
```sql
mysql> select version();
+-----------------------------------------------------+
| version() |
+-----------------------------------------------------+
| 8.0.11-TiDB-v9.0.0-beta.1.pre-640-g24903d6b24-dirty |
+-----------------------------------------------------+
1 row in set (0.00 sec)
```
Contributor guide
Research direction
No source file or test is named. Start by running the supplied two-session SQL reproduction and compare locking for partitioned t0 with the unpartitioned t0_oracle; trace the transaction and partition lock paths. Done means UPDATE observes consistent lock-wait behavior in both cases, with regression coverage for the difference.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- sql
- Domain
- databases, distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100