Inconsistent lock behavior on partitioned and non-partitioned tables
Author: FullDuplexFishCreated Sep 16, 2026Updated Sep 17, 2026
Labelstype/bugcontributionsig/transactionseverity/majoraffects-7.5affects-8.1affects-8.5affects-26.3
Bug Report
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)
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:
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)
mysql> select version();
+-----------------------------------------------------+
| version() |
+-----------------------------------------------------+
| 8.0.11-TiDB-v9.0.0-beta.1.pre-640-g24903d6b24-dirty |
+-----------------------------------------------------+
1 row in set (0.00 sec)Source: pingcap/tidb