Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
11.2.2, (15)
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11, 11.0(EOL), 11.1(EOL), 11.2(EOL), 11.3(EOL), 11.4 -
Ubuntu 20.04
Description
How to repeat:
/* init */ CREATE TABLE t(a INT PRIMARY KEY, b INT UNIQUE); |
/* init */ INSERT INTO t(a) VALUES (1); |
/* t1 */ SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE; |
/* t2 */ SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE; |
|
/* t1 */ BEGIN; |
/* t2 */ BEGIN; |
/* t1 */ INSERT INTO t(a) VALUES (2); |
/* t2 */ SELECT a, b FROM t WHERE TRUE; -- [(1, null), (1, null)] |
/* t1 */ ROLLBACK; |
/* t2 */ COMMIT; |
The SELECT statement of t2 was initially blocked by t1. Then it recovered after t1's ROLLBACK, but its query result contained two identical records (1, null). Interestingly, removing the UNIQUE constraint on column b eliminates this anomaly.
Attachments
Issue Links
- causes
-
MDEV-36639 innodb_snapshot_isolation=1 gives error for not committed row changes
-
- Closed
-
- is blocked by
-
MDEV-26642 Weird SELECT view when a record is modified to the same value by two transactions
-
- Closed
-
-
MDEV-26643 Inconsistent behaviors of UPDATE under RU & RC isolation level
-
- Closed
-
-
MDEV-32898 Phantom rows caused by UPDATE of PRIMARY KEY
-
- Closed
-
- is caused by
-
MDEV-20605 Awaken transaction can miss inserted by other transaction records due to wrong persistent cursor restoration
-
- Closed
-
Activity
Transition | Time In Source Status | Execution Times |
---|
|
19h 21m | 1 |
|
20m 6s | 1 |
|
1h 18m | 1 |
|
13d 1h 31m | 1 |
|
1m 55s | 1 |