Details

    • Type: Technical task
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:

      Description

      LevelDB uses the global value of leveldb_lock_wait_timeout, but ignores the session one.

      
      --enable_connect_log
      
      create table t1 (pk int primary key, i int) engine=LevelDB;
      set global leveldb_lock_wait_timeout = 2;
      begin;
      insert into t1 values (1,1);
      
      --connect (con1,localhost,root,,)
      set session leveldb_lock_wait_timeout = 5;
      select now();
      --error ER_LOCK_WAIT_TIMEOUT
      insert into t1 values (1,100);
      select now();
      
      --connection default
      commit;
      

      Output shows that the timeout is 2 seconds, not 5:

      create table t1 (pk int primary key, i int) engine=LevelDB;
      set global leveldb_lock_wait_timeout = 2;
      begin;
      insert into t1 values (1,1);
      connect  con1,localhost,root,,;
      set session leveldb_lock_wait_timeout = 5;
      select now();
      now()
      2013-01-14 17:34:38
      insert into t1 values (1,100);
      ERROR HY000: Lock wait timeout exceeded; try restarting transaction
      select now();
      now()
      2013-01-14 17:34:40
      connection default;
      commit;
      
      

      Here is a tiny modification to leveldb.test which also shows the problem (unfortunately, I don't see a better way than sleep):

      === modified file 'mysql-test/t/leveldb.test'
      --- mysql-test/t/leveldb.test   2013-01-14 13:15:29 +0000
      +++ mysql-test/t/leveldb.test   2013-01-14 14:19:05 +0000
      @@ -350,6 +350,7 @@ set leveldb_lock_wait_timeout=1000; # se
         update t17 set col1='UPD2-CC' where pk='row2';
       
       connection con1;
      +--sleep 2
       rollback;
       
       connection default;
      

      This part of the test sets the session timeout to 1000 seconds, starts an update, then switches to the connection which holds the lock and releases it. Then it returns to the first connection and checks that the update worked. However, there is no delay anywhere in the process, the operations are fast and well within 1 second, so the test doesn't really check that the timeout value affects the outcome. With the delay, the test starts failing with ER_LOCK_WAIT_TIMEOUT at line 357, which is not supposed to happen.

      revision-id: psergey@askmonty.org-20130114131529-qv3531bw9fdklwob
      revno: 4483
      branch-nick: mysql-5.6-leveldb
      

        Gliffy Diagrams

          Attachments

            Activity

            There are no comments yet on this issue.

              People

              • Assignee:
                psergey Sergei Petrunia
                Reporter:
                elenst Elena Stepanova
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 1 hour
                  1h