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

Galera: Server does not honor metadata locking (even inside the same node)

        Details

        • Type: Bug
        • Status: Closed
        • Priority: Major
        • Resolution: Not a Bug
        • Affects Version/s: None
        • Fix Version/s: 5.5.25-galera
        • Component/s: None
        • Labels:
          None

          Description

          --connection con1
CREATE TABLE t1 (i INT PRIMARY KEY);
BEGIN;
INSERT INTO t1 VALUES (1);

--connection con2
ALTER TABLE t1 ADD COLUMN b CHAR;

--connection con1
COMMIT;

          Normally, in the scenario above the 2nd connection would wait for a metadata lock on t1 until con1 finishes the transaction, or lock_wait_timeout occurs, whichever happens first. However, if server is running as a Galera node, ALTER TABLE is executed right away, despite the locks that con1 holds; and the transaction in con1 will be rejected.

          Explicit BEGIN/COMMIT here are just to make the test deterministic, in fact it happens just as well on a single-statement transaction with autocommit.

          Limitations page (http://www.codership.com/wiki/doku.php?id=limitations) mentions LOCK statements, but does not say that internal locking is also not supported. Besides, this kind of scenario does not involve any other nodes.

          bzr version-info

          revision-id: seppo.jaakola@codership.com-20120808224721-89h8nxmfk9uvp708
date: 2012-08-09 01:47:21 +0300
build-date: 2012-08-20 20:31:14 +0400
revno: 3343

            Gliffy Diagrams

              Attachments

                Issue Links

                relates to

                Bug - A problem which impairs or prevents the functions of the product. MDEV-523 Galera: Server crashes with SIGABRT, SIGSEGV or deadlocks on concurrent DDL/DML flow

                • Major - Major loss of function.
                • Closed

                Bug - A problem which impairs or prevents the functions of the product. MDEV-542 Galera: Assertion `! is_set() || can_overwrite_status' failed in Diagnostics_area::set_ error_status on concurrent DDL

                • Major - Major loss of function.
                • Closed

                  Activity

                  Ascending order - Click to sort in descending order
                  Hide
                  Permalink
                  seppo Seppo Jaakola added a comment -

                  Galera processes all DDL statements under "Total Order Isolation", where the DDL statement is replicated up front and with high priority.
                  In this test scenario the con1 DML transaction (BEGIN; INSERT...) is still local state and not known by replicator when the ALTER from con2 is replicated. Then ALTER will gain higher priority and will override the DML transaction. This is natural behavior for DDLs in Galera Cluster.

                  Show
                  seppo Seppo Jaakola added a comment - Galera processes all DDL statements under "Total Order Isolation", where the DDL statement is replicated up front and with high priority. In this test scenario the con1 DML transaction (BEGIN; INSERT...) is still local state and not known by replicator when the ALTER from con2 is replicated. Then ALTER will gain higher priority and will override the DML transaction. This is natural behavior for DDLs in Galera Cluster.
                  Hide
                  Permalink
                  seppo Seppo Jaakola added a comment -

                  This is expected behaviour of DDL processing in Galera Cluster

                  Show
                  seppo Seppo Jaakola added a comment - This is expected behaviour of DDL processing in Galera Cluster

                    People

                    • Assignee:
                      seppo Seppo Jaakola
                      Reporter:
                      elenst Elena Stepanova
                    • Votes:
                      0 Vote for this issue
                      Watchers:
                      2 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 - 6 minutes
                        6m