Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Critical
-
Resolution: Unresolved
-
5.5, 10.0, 10.1, 10.5.12, 10.2, 10.3, 10.4, 10.5, 10.6
-
OS: Ubuntu-20.04
Description
Under REPEATABLE-READ isolation level, if two transactions concurrently modify the same row to the same value, the transaction that modifies later does not see the modified content.
/* init */ create table t(a int, b int); |
/* init */ insert into t values (0, 0), (1, 1), (2, 2); |
 |
/* s1 */ begin; |
/* s1 */ select * from t; -- [(0, 0), (1, 1), (2, 2)] |
/* s2 */ begin; |
/* s2 */ update t set a = 10 where b = 1; |
/* s2 */ commit; |
/* s1 */ select * from t; -- [(0, 0), (1, 1), (2, 2)] |
/* s1 */ update t set a = 10 where true; |
/* s1 */ select * from t; -- [(10, 0), (1, 1), (10, 2)] |
/* s1 */ commit; |
The result of final SELECT should be (10, 0), (10, 1), (10, 2).
I think it is so weird for session 1 to see the second row is still (1, 1) after the successful execution of an UPDATE with the "WHERE TRUE" predicate.
So I think it will be better for s1 to see all records it updates regardless of whether the values before and after the UPDATE are the same.
Attachments
Issue Links
- relates to
-
MDEV-14589 InnoDB should not lock a delete-marked record
-
- Closed
-
-
MDEV-26643 Inconsistent behaviors of UPDATE under RU & RC isolation level
-
- Open
-
-
MDEV-26671 Inconsistent SELECT View when modify a record added by another transaction
-
- Open
-
-
MDEV-29565 Inconsistent read and write, which use the same predicate (WHERE clause)
-
- Confirmed
-