Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-37281

incorrect isolation level in update with unique using hash or without overlap

    XMLWordPrintable

Details

    • 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

          Activity

            People

              serg Sergei Golubchik
              serg Sergei Golubchik
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: