pingcap / pingcap/tidb

Inconsistent lock behavior on partitioned and non-partitioned tables

Open
#71,226 4 comments 0 reactions 0 assignees View on GitHub
affects-25.10 affects-26.3 affects-7.5 affects-8.1 affects-8.5 contribution severity/major sig/transaction type/bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.