Repository navigation
Unexpected lock behavior for point get FOR UPDATE read on unique key #66571
Description
Bug Report
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)
create table t(a int, b int, primary key(a) nonclustered);
insert into t values(1,1);
set global tidb_txn_mode='pessimistic';
set global innodb_lock_wait_timeout=50;
set global max_execution_time=0;
set global tidb_pessimistic_txn_fair_locking=1;
Session1
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from t where a=1 for update;
+---+------+
| a | b |
+---+------+
| 1 | 1 |
+---+------+
1 row in set (0.01 sec)
Session2
mysql> begin;
Query OK, 0 rows affected (0.01 sec)
mysql> select * from t where a=1 for update;
+---+------+
| a | b |
+---+------+
| 1 | 1 |
+---+------+
1 row in set (12.04 sec)
2. What did you expect to see? (Required)
The for update query on Session2 waits for the lock and reports Lock wait timeout exceeded at 50s.
3. What did you see instead (Required)
The query acquired the lock.
4. What is your TiDB version? (Required)
v8.5.4
Activity
jebter commentedon Mar 2, 2026
@cfzjywxk PTAL
cfzjywxk commentedon Mar 2, 2026
Root cause
The cause is the ttl manger is unexpectedly reset in this case.
For
PointGetExecwith unique index lock operation:Here when
lock_keyis called, the ttl manager is reset by https://github.com/tikv/client-go/blob/master/txnkv/transaction/txn.go#L1762 unexpecdly, resulting loss of heartbeat.From the re-producing logs:
Workaround
Disable the
tidb_pessimistic_txn_fair_locking.Fix
For quick fix
Guard against
lastPrimaryKey == nil:This ensures the heartbeat is only reset when there's an actual primary key change between
retries, not on the first execution where lastPrimaryKey hasn't been set yet.
We also need to consider the retry safety for this, reset only when primary is newly selected in this LockKeys call (for example , pass assignedPrimaryKey local bool into
resetTTLManagerForAggressiveLockingMode). Otherwise, if primary changed on retry we can still reset repeatedly on later LockKeys calls in the same attempt.cfzjywxk commentedon Mar 2, 2026
@MyonKeminta Please check and label the affected versions
MyonKeminta commentedon Mar 2, 2026
Simply excluding
lastPrimaryKey == nildoesn't fix the problem as the case happens after a retry.MyonKeminta commentedon Mar 2, 2026
The problem is introduced by tikv/client-go#1522 and is only included in master and release-8.5 .
txn: Add test for the issue that transaction using fair locking multi…
txn: Fix and add test for the issue that transaction using fair locki…
kennedy8312 commentedon Sep 22, 2026
/report customer