Commits on Aug 21, 2018

1. Ingore setting m_lock_rows if lock_type == TL_IGNORE …

   Original report: https://jira.mariadb.org/browse/MDEV-15816
   
   To reproduce this bug just following below steps,
   
   client 1:
   USE test;
   CREATE TABLE t1 (i INT) ENGINE=MyISAM;
   HANDLER t1 OPEN h;
   CREATE TABLE t2 (i INT) ENGINE=RocksDB;
   LOCK TABLES t2 WRITE;
   
   client 2:
   FLUSH TABLES WITH READ LOCK;
   
   client 1:
   INSERT INTO t2 VALUES (1);
   
   So client 1 acquired the lock and set m_lock_rows = RDB_LOCK_WRITE.
   Then client 2 calls store_lock(TL_IGNORE) and m_lock_rows was wrongly
   set to RDB_LOCK_NONE, as below
   
    #0  myrocks::ha_rocksdb::store_lock (this=0x7fffbc03c7c8, thd=0x7fffc0000ba0, to=0x7fffc0011220, lock_type=TL_IGNORE)
    facebook#1  get_lock_data (thd=0x7fffc0000ba0, table_ptr=0x7fffe84b7d20, count=1, flags=2)
    facebook#2  mysql_lock_abort_for_thread (thd=0x7fffc0000ba0, table=0x7fffbc03bbc0)
    facebook#3  THD::notify_shared_lock (this=0x7fffc0000ba0, ctx_in_use=0x7fffbc000bd8, needs_thr_lock_abort=true)
    facebook#4  MDL_lock::notify_conflicting_locks (this=0x555557a82380, ctx=0x7fffc0000cc8)
    facebook#5  MDL_context::acquire_lock (this=0x7fffc0000cc8, mdl_request=0x7fffe84b8350, lock_wait_timeout=2)
    facebook#6  Global_read_lock::lock_global_read_lock (this=0x7fffc0003fe0, thd=0x7fffc0000ba0)
   
   Finally, client 1 "INSERT INTO..." hits the Assertion 'm_lock_rows == RDB_LOCK_WRITE'
   failed in myrocks::ha_rocksdb::write_row()
   
   Fix this bug by not setting m_locks_rows if lock_type == TL_IGNORE.

   

   minggr committed Aug 21, 2018
   Configuration menu

   • View commit details
   • Copy full SHA for 7b8574c
   • Browse repository at this point

   Copy the full SHA

   7b8574c View commit details

   Browse the repository at this point in the history