Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
11.4, 11.8
-
None
-
Can result in unexpected behaviour
Description
--source include/have_innodb.inc
|
create table t1 (id int, e varchar(100), a int, unique (e) using hash) engine=innodb; |
insert t1 values(10, '2000-01-01', 0); |
insert t1 values(20, '2000-01-02', 1); |
insert t1 values(30, '2000-01-03', 2); |
set transaction isolation level read committed; |
start transaction; |
update t1 set a=10 where a=0; |
--connect con1,localhost,root
|
set transaction isolation level read committed; |
update t1 set a=20 where a=1; |
connection default; |
drop table t1; |
after delete/update refactoring, an update of InnoDB table that has unique constraint WITHOUT OVERLAPS or USING HASH was issuing handler calls in the wrong order (external_lock from create_lookup_handler was done before store_lock), which effectively caused the current isolation mode to be ignored and the table was always locked as in repeatable read.
Attachments
Issue Links
- is duplicated by
-
MDEV-36791 Assertion failures after failed DML on table with app period and vector key
-
- Closed
-