Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
None
-
None
-
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
|
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.