Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
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
Attachments
Issue Links
- duplicates
-
MDEV-32898 Phantom rows caused by UPDATE of PRIMARY KEY
-
- Closed
-
--source include/have_innodb.inc
create table t1 (id int AUTO_INCREMENT, addr varchar(20), PRIMARY KEY (`id`)) ENGINE=InnoDB;
insert into t1 (id,addr) values (1,'aaa');
start transaction;
select addr from t1 where id=1;
connect (con1,localhost,root,,);
connection con1;
update t1 set addr='bbb' where id=1;
connection default;
update t1 set addr='bbb' where id=1;
select addr from t1 where id=1;
drop table t1;
Confirmed on 10.5.26-9e74a7f4f330cde50143ce94fdf09be68abebba0 and 11.6-preview-42294b8cd2cbb72c1d5da6058dd6f0c55669def7
Thanks for the bug report.