Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Critical
-
Resolution: Unresolved
-
10.3.39, 10.5.25, 11.6.1
Description
Prepare test data:
CREATE TABLE ApiLog (id int AUTO_INCREMENT, addr varchar(20), PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; |
 |
insert into ApiLog (id,addr) values (1,'aaa'); |
Reproduce steps:
1. start session 1 and do select
start transaction; |
select addr from ApiLog where id=1; -- show original value "aaa" |
NOTE: if not run this select statement here, the bug cannot reproduce.
2. another session change value of the same row
update ApiLog set addr='bbb' where id=1; |
3. back to session 1, do update and select:
-- NOTE: update using the same value as step 2
|
update ApiLog set addr='bbb' where id=1; |
select addr from ApiLog where id=1; |
-- expect 'bbb', actual still 'aaa'! |
Expected:
select result should be the same as the one used in update statement.
Actual:
wrong select result after update.
I consider this is a serious bug as the affected statements are basic.
In my web service multiple threads handle tasks, and update task status field after done. The bug causes my program fail to check field and crash after dead loop.
NOTE: mariadb 5.5.68 is good version. I verified mysql 8.0.20 is a bad version as well, so I create the same issue on mysql: https://bugs.mysql.com/bug.php?id=115463&thanks=4