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

KB page for GET_LOCK() should be clarified and improved

    XMLWordPrintable

    Details

      Description

      KB page about GET_LOCK() function (https://mariadb.com/kb/en/library/get_lock/) now says:

      "If you have a lock obtained with GET_LOCK(), it is released when you execute RELEASE_LOCK(), execute a new GET_LOCK(), or your connection terminates (either normally or abnormally). Locks obtained with GET_LOCK() do not interact with transactions. That is, committing a transaction does not release any such locks obtained during the transaction.

      MariaDB starting with 10.0.2

      Konstantin "Kostja" Osipov contributed a patch (MDEV-3917) which allows a user to set many user-level locks in one connection with the GET_LOCK() call."

      With the majority of versions users care about now being 10.0.2+ and relying on MDL-based GET_LOCK() implementation we should better describe current behavior (multiple locks per connection, no release of any locks by GET_LOCK() etc in the main text and then add the details about historical behavior as notes.

      This KB page also clearly misses examples of outputs from information_schema.metadata_lock_info; when locks are acquired or are waited for by other connection, as well as clear statement that repeatable GET_LOCK('name') calls for the same 'name' in the same connection does not do anything like lock release and re-acquiring of the lock etc.

      See also upstream https://bugs.mysql.com/bug.php?id=93043 for some problems in upstream documentation for the function (that we should avoid when adding details).

        Attachments

          Activity

            People

            • Assignee:
              greenman Ian Gilfillan
              Reporter:
              valerii Valerii Kravchuk
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: