Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Duplicate
-
10.4.5, 11.2.2, 10.5.29
-
windows 10
-
Unexpected results
Description
When two transactions run concurrently, the first transaction (Tx1) at REPEATABLE READ level should not see changes committed by the second transaction (Tx2) after Tx1 has established its snapshot (via its first read operation). However, we have observed that a subsequent SELECT query within Tx1 does see the data updated by Tx2, which breaks the isolation guarantee.
/* init */ CREATE TABLE mtest( |
c0 TEXT,
|
c1 DOUBLE, |
c2 CHAR(18), |
c3 INT UNIQUE, |
c4 INT |
);
|
/* init */ INSERT INTO mtest(c2) VALUES ('*A'); |
/* init */ INSERT IGNORE INTO mtest(c0, c2) VALUES ('{i{Yd{8My', 'X'); |
|
|
/* s1 */ BEGIN; |
/* s1 */ SELECT * FROM mtest WHERE TRUE; |
+-----------+-----------+---------+----------+---------+ |
| c0 | c1 | c2 | c3 | c4 |
|
+-----------+----------+---------+---------+---------+ |
| NULL | NULL | *A | NULL | NULL | |
| {i{Yd{8My | NULL | X | NULL | NULL | |
+-----------+---------+---------+--------+---------+ |
/* s2 */ BEGIN; |
/* s2 */ UPDATE mtest SET c0="", c1=0.4084982064063216, c2="1G5z" WHERE -1542493454; |
/* s2 */ COMMIT; |
/* s1 */ UPDATE mtest SET c4=91 WHERE TRUE; |
/* s1 */ SELECT * FROM mtest WHERE TRUE; |
+--------+-----------------------+------+------+------+ |
| c0 | c1 | c2 | c3 | c4 |
|
+-------+------------------------+------+------+------+ |
| | 0.4084982064063216 | 1G5z | NULL | 91 | |
| | 0.4084982064063216 | 1G5z | NULL | 91 | |
+------+-------------------------+------+------+------+ |
|
/* s1 */ COMMIT; |
|
Attachments
Issue Links
- duplicates
-
MDEV-32898 Phantom rows caused by UPDATE of PRIMARY KEY
-
- Closed
-