optimistic locks block read
- 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)
1. `create table t(pk int primary key, v int, uk int, nuk int, key uk1(uk), key nuk1(nuk)) partition by list(pk)
(PARTITION p0 VALUES in (1,2),
PARTITION p1 VALUES in (3,4),
PARTITION p2 VALUES in (5,6),
PARTITION p3 VALUES in (7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100))`
2. // Read meets optimistic locks. Skip them and read old data
drop table if exists t
insert into t values (1, 1, 1, 1), (2, 2, 2, 2), (3, 3, 3, 3)
try(cli.EnableFailpoint(resource.TiDB, beforeCommitFp, "pause"))
begin pessimistic
update t set v = v + 1
commit
begin
select t1.v from (%s) as t1 order by t1.v
### 2. What did you expect to see? (Required)
read successful
### 3. What did you see instead (Required)
read fail with "optimistic locks shouldn't block read"
### 4. What is your TiDB version? (Required)
master
Contributor guide
Assessment
This issue has not been assessed yet.