pingcap/tidb

Query in transaction may return rows with same unique index column value

Open

#24,195 opened on Apr 21, 2021

View on GitHub
 (14 comments) (0 reactions) (1 assignee)Go (6,186 forks)batch import
affects-5.0affects-5.1affects-5.2affects-5.3affects-5.4affects-6.0affects-6.1affects-6.2affects-6.3affects-6.4affects-6.5affects-6.6affects-7.0affects-7.1help wantedseverity/moderatesig/transactiontype/bug

Repository metrics

Stars
 (40,090 stars)
PR merge metrics
 (Avg merge 14d 4h) (346 merged PRs in 30d)

Description

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

drop table if exists t;
create table t (a int, b int, primary key (a, b) /*T![clustered_index] nonclustered */);
insert into t values (1, 10);
begin optimistic;
insert into t values (1, 10);
select * from t;
commit;

2. What did you expect to see? (Required)

Only one row is returned by the select statement.

3. What did you see instead (Required)

mysql> /* t */ select * from t; -- (1, 10), (1, 10)
+---+----+
| a | b  |
+---+----+
| 1 | 10 |
| 1 | 10 |
+---+----+
2 rows in set (0.00 sec)

mysql> /* t */ commit;
ERROR 1062 (23000): Duplicate entry '1-10' for key 'PRIMARY'

4. What is your TiDB version? (Required)

Release Version: v5.0.0-43-g41871e0c8 Edition: Community Git Commit Hash: 41871e0c8e5e4b0601dd94d09342bc0317cbb8cb Git Branch: release-5.0 UTC Build Time: 2021-04-20 09:24:52 GoVersion: go1.13 Race Enabled: false TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306 Check Table Before Drop: false

Contributor guide

Research direction
Investigate the transaction handling code, specifically how reads are performed during an optimistic transaction. The bug suggests that unique constraint checks are not applied to reads, causing duplicate rows to be returned. Trace the code path for select statements in a transaction and check how duplicate detection is handled.
Tech stack
go
Domain
database
Issue type
Bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
4
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
3-5 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
Go
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
35