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

        • Type: Bug
        • Status: Closed
        • Priority: Major
        • Resolution: Not a Bug
        • Affects Version/s: 10.0.10
        • Fix Version/s: None
        • Component/s: None
        • Environment:
          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.

            Gliffy Diagrams

              Attachments

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                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.

                Show
                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.
                Hide
                Permalink
                Profforg Alexander Loginov added a comment -

                Oh, it seems like i misunderstand the word.

                Issue can be closed.

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

                  People

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

                    Dates

                    • Due:
                      Created:
                      Updated:
                      Resolved: