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

tokudb_lock_timeout 0 is not working as expected in MariaDB compared to Tokutek's version

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Not a Bug
    • 10.0.10
    • None
    • None
    • Debian Wheezy x64

    Description

      Hi.

      From Tokutek documentation http://www.tokutek.com/wp-content/uploads/2013/10/mariadb-5.5.30-tokudb-7.1.0-users-guide.pdf:

      4.2.5 tokudb_lock_timeout
      ....
      A value of 0 disables lock waits
      ....

      If tokudb_lock_timeout = 0, then lock waits should not happen. However with MariaDB 10.0.10 i've see, that if i request a table lock, the request refused with "#1205 - Lock wait timeout exceeded; try restarting transaction", so MariaDB now actually set lock timeout to zero milliseconds.

      I think it will be better to match the behaviour with Tokutek version and disable lock waits, if tokudb_lock_timeout = 0.

      Sincerely,

      Alex.

      Attachments

        Activity

          Hi Alexander,

          What do you expect to happen when lock waits are disabled?
          From what I see, the Tokutek version behaves exactly the same way:

          MySQL [test]> set tokudb_lock_timeout=0;
          Query OK, 0 rows affected (0.00 sec)
           
          MySQL [test]> update t1 set i = 2;
          ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
          MySQL [test]> select @@version;
          +---------------------+
          | @@version           |
          +---------------------+
          | 5.5.36-tokudb-7.1.5 |
          +---------------------+
          1 row in set (0.00 sec)
           
          MySQL [test]> select @@version_comment;
          +------------------------------+
          | @@version_comment            |
          +------------------------------+
          | MySQL Community Server (GPL) |
          +------------------------------+
          1 row in set (0.00 sec)

          and it's the only reasonable way I can think of – 0 means that waiting is disabled, not the timeout; it doesn't mean that the statement will actually break the lock of another transaction. If waiting is disabled, the timeout happens right away.

          elenst Elena Stepanova added a comment - Hi Alexander, What do you expect to happen when lock waits are disabled? From what I see, the Tokutek version behaves exactly the same way: MySQL [test]> set tokudb_lock_timeout=0; Query OK, 0 rows affected (0.00 sec)   MySQL [test]> update t1 set i = 2; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction MySQL [test]> select @@version; + ---------------------+ | @@version | + ---------------------+ | 5.5.36-tokudb-7.1.5 | + ---------------------+ 1 row in set (0.00 sec)   MySQL [test]> select @@version_comment; + ------------------------------+ | @@version_comment | + ------------------------------+ | MySQL Community Server (GPL) | + ------------------------------+ 1 row in set (0.00 sec) and it's the only reasonable way I can think of – 0 means that waiting is disabled, not the timeout; it doesn't mean that the statement will actually break the lock of another transaction. If waiting is disabled, the timeout happens right away.

          Oh, it seems like i misunderstand the word.

          Issue can be closed.

          Profforg Alexander Loginov added a comment - Oh, it seems like i misunderstand the word. Issue can be closed.

          People

            elenst Elena Stepanova
            Profforg Alexander Loginov
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.