mariadb/mysql-test/main/schema.result

102 lines
2.5 KiB
Text
Raw Normal View History

create schema foo;
show create schema foo;
Database Create Database
foo CREATE DATABASE `foo` /*!40100 DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci */
show schemas;
Database
foo
information_schema
2008-04-02 10:06:36 +02:00
mtr
mysql
performance_schema
sys
test
drop schema foo;
Bug #48940 MDL deadlocks against mysql_rm_db This deadlock would occur between two connections A and B if statements where executed in the following way: 1) Connection A executes a DML statement against table s1.t1 with autocommit off. This causes a shared metadata lock on s1.t1 to be acquired. (With autocommit on, the metadata lock will be dropped once the statment completes and the deadlock will not occour.) 2) Connection B tries to DROP DATABASE s1. This will block against the metadata lock connection A holds on s1.t1. While blocking, connection B will hold the LOCK_mysql_create_db mutex. 3) Connection A tries to ALTER DATABASE s1. This will block when trying to get LOCK_mysql_create_db mutex held by connection B. 4) Deadlock between DROP DATABASE and ALTER DATABASE (which has autocommit off). If Connection A used an explicitly started transaction rather than having autocommit off, this deadlock did not happen as ALTER DATABASE is disallowed inside transactions. This patch fixes the problem by changing ALTER DATABASE to cause an implicit commit before executing. This will cause the metadata lock on s1.t1 to be dropped, allowing DROP DATABASE to proceed. This will in turn cause the LOCK_mysql_create_db mutex to be unlocked, allowing ALTER DATABASE to proceed. Note that SQL commands other than ALTER DATABASE that also use LOCK_mysql_create_db, already cause an implicit commit. Incompatible change: ALTER DATABASE (and its synonym ALTER SCHEMA) now cause an implicit commit. This must be reflected in the documentation. Test case added to schema.test. sql/sql_parse.cc: Added CF_AUTO_COMMIT_TRANS to SQLCOM_ALTER_DB. Removed thd->active_transaction() checks from SQLCOM_DROP_DB, SQLCOM_ALTER_DB_UPGRADE and SQLCOM_ALTER_DB as these statements cause an implicit commit.
2009-12-15 14:18:10 +01:00
#
# Bug #48940 MDL deadlocks against mysql_rm_db
#
connect con2, localhost, root;
connection default;
Bug #48940 MDL deadlocks against mysql_rm_db This deadlock would occur between two connections A and B if statements where executed in the following way: 1) Connection A executes a DML statement against table s1.t1 with autocommit off. This causes a shared metadata lock on s1.t1 to be acquired. (With autocommit on, the metadata lock will be dropped once the statment completes and the deadlock will not occour.) 2) Connection B tries to DROP DATABASE s1. This will block against the metadata lock connection A holds on s1.t1. While blocking, connection B will hold the LOCK_mysql_create_db mutex. 3) Connection A tries to ALTER DATABASE s1. This will block when trying to get LOCK_mysql_create_db mutex held by connection B. 4) Deadlock between DROP DATABASE and ALTER DATABASE (which has autocommit off). If Connection A used an explicitly started transaction rather than having autocommit off, this deadlock did not happen as ALTER DATABASE is disallowed inside transactions. This patch fixes the problem by changing ALTER DATABASE to cause an implicit commit before executing. This will cause the metadata lock on s1.t1 to be dropped, allowing DROP DATABASE to proceed. This will in turn cause the LOCK_mysql_create_db mutex to be unlocked, allowing ALTER DATABASE to proceed. Note that SQL commands other than ALTER DATABASE that also use LOCK_mysql_create_db, already cause an implicit commit. Incompatible change: ALTER DATABASE (and its synonym ALTER SCHEMA) now cause an implicit commit. This must be reflected in the documentation. Test case added to schema.test. sql/sql_parse.cc: Added CF_AUTO_COMMIT_TRANS to SQLCOM_ALTER_DB. Removed thd->active_transaction() checks from SQLCOM_DROP_DB, SQLCOM_ALTER_DB_UPGRADE and SQLCOM_ALTER_DB as these statements cause an implicit commit.
2009-12-15 14:18:10 +01:00
CREATE SCHEMA schema1;
CREATE TABLE schema1.t1 (a INT);
START TRANSACTION;
Bug #48940 MDL deadlocks against mysql_rm_db This deadlock would occur between two connections A and B if statements where executed in the following way: 1) Connection A executes a DML statement against table s1.t1 with autocommit off. This causes a shared metadata lock on s1.t1 to be acquired. (With autocommit on, the metadata lock will be dropped once the statment completes and the deadlock will not occour.) 2) Connection B tries to DROP DATABASE s1. This will block against the metadata lock connection A holds on s1.t1. While blocking, connection B will hold the LOCK_mysql_create_db mutex. 3) Connection A tries to ALTER DATABASE s1. This will block when trying to get LOCK_mysql_create_db mutex held by connection B. 4) Deadlock between DROP DATABASE and ALTER DATABASE (which has autocommit off). If Connection A used an explicitly started transaction rather than having autocommit off, this deadlock did not happen as ALTER DATABASE is disallowed inside transactions. This patch fixes the problem by changing ALTER DATABASE to cause an implicit commit before executing. This will cause the metadata lock on s1.t1 to be dropped, allowing DROP DATABASE to proceed. This will in turn cause the LOCK_mysql_create_db mutex to be unlocked, allowing ALTER DATABASE to proceed. Note that SQL commands other than ALTER DATABASE that also use LOCK_mysql_create_db, already cause an implicit commit. Incompatible change: ALTER DATABASE (and its synonym ALTER SCHEMA) now cause an implicit commit. This must be reflected in the documentation. Test case added to schema.test. sql/sql_parse.cc: Added CF_AUTO_COMMIT_TRANS to SQLCOM_ALTER_DB. Removed thd->active_transaction() checks from SQLCOM_DROP_DB, SQLCOM_ALTER_DB_UPGRADE and SQLCOM_ALTER_DB as these statements cause an implicit commit.
2009-12-15 14:18:10 +01:00
INSERT INTO schema1.t1 VALUES (1);
connection con2;
Bug #48940 MDL deadlocks against mysql_rm_db This deadlock would occur between two connections A and B if statements where executed in the following way: 1) Connection A executes a DML statement against table s1.t1 with autocommit off. This causes a shared metadata lock on s1.t1 to be acquired. (With autocommit on, the metadata lock will be dropped once the statment completes and the deadlock will not occour.) 2) Connection B tries to DROP DATABASE s1. This will block against the metadata lock connection A holds on s1.t1. While blocking, connection B will hold the LOCK_mysql_create_db mutex. 3) Connection A tries to ALTER DATABASE s1. This will block when trying to get LOCK_mysql_create_db mutex held by connection B. 4) Deadlock between DROP DATABASE and ALTER DATABASE (which has autocommit off). If Connection A used an explicitly started transaction rather than having autocommit off, this deadlock did not happen as ALTER DATABASE is disallowed inside transactions. This patch fixes the problem by changing ALTER DATABASE to cause an implicit commit before executing. This will cause the metadata lock on s1.t1 to be dropped, allowing DROP DATABASE to proceed. This will in turn cause the LOCK_mysql_create_db mutex to be unlocked, allowing ALTER DATABASE to proceed. Note that SQL commands other than ALTER DATABASE that also use LOCK_mysql_create_db, already cause an implicit commit. Incompatible change: ALTER DATABASE (and its synonym ALTER SCHEMA) now cause an implicit commit. This must be reflected in the documentation. Test case added to schema.test. sql/sql_parse.cc: Added CF_AUTO_COMMIT_TRANS to SQLCOM_ALTER_DB. Removed thd->active_transaction() checks from SQLCOM_DROP_DB, SQLCOM_ALTER_DB_UPGRADE and SQLCOM_ALTER_DB as these statements cause an implicit commit.
2009-12-15 14:18:10 +01:00
DROP SCHEMA schema1;
connection default;
ALTER SCHEMA schema1 DEFAULT CHARACTER SET utf8;
Got one of the listed errors
COMMIT;
connection con2;
connection default;
disconnect con2;
Bug #49988 MDL deadlocks with mysql_create_db, reload_acl_and_cache This was a deadlock between LOCK TABLES/CREATE DATABASE in one connection and DROP DATABASE in another. It only happened if the table locked by LOCK TABLES was in the database to be dropped. The deadlock is similar to the one in Bug#48940, but with LOCK TABLES instead of an active transaction. The order of events needed to trigger the deadlock was: 1) Connection 1 locks table db1.t1 using LOCK TABLES. It will now have a metadata lock on the table name. 2) Connection 2 issues DROP DATABASE db1. This will wait inside the MDL subsystem for the lock on db1.t1 to go away. While waiting, it will hold the LOCK_mysql_create_db mutex. 3) Connection 1 issues CREATE DATABASE (database name irrelevant). This will hang trying to lock the same mutex. Since this is the connection holding the metadata lock blocking Connection 2, we have a deadlock. This deadlock would also happen for earlier trees without MDL, but there DROP DATABASE would wait for a table to be removed from the table definition cache. This patch fixes the problem by prohibiting CREATE DATABASE in LOCK TABLES mode. In the example above, this prevents Connection 1 from hanging trying to get the LOCK_mysql_create_db mutex. Note that other commands that use LOCK_mysql_create_db (ALTER/DROP DATABASE) are already prohibited in LOCK TABLES mode. Incompatible change: CREATE DATABASE is now disallowed in LOCK TABLES mode. Test case added to schema.test. mysql-test/t/drop.test: Updates the test for Bug#21216 by swapping the order of CREATE DATABASE and LOCK TABLES. This is now needed as CREATE DATABASE is prohibited in LOCK TABLES mode. mysql-test/t/schema.test: Test case for Bug#49988 added. Also fixes a problem with the test for Bug#48940 where the result would differ for embedded server.
2010-01-12 16:15:21 +01:00
#
# Bug #49988 MDL deadlocks with mysql_create_db, reload_acl_and_cache
#
connect con2, localhost, root;
connection default;
Bug #49988 MDL deadlocks with mysql_create_db, reload_acl_and_cache This was a deadlock between LOCK TABLES/CREATE DATABASE in one connection and DROP DATABASE in another. It only happened if the table locked by LOCK TABLES was in the database to be dropped. The deadlock is similar to the one in Bug#48940, but with LOCK TABLES instead of an active transaction. The order of events needed to trigger the deadlock was: 1) Connection 1 locks table db1.t1 using LOCK TABLES. It will now have a metadata lock on the table name. 2) Connection 2 issues DROP DATABASE db1. This will wait inside the MDL subsystem for the lock on db1.t1 to go away. While waiting, it will hold the LOCK_mysql_create_db mutex. 3) Connection 1 issues CREATE DATABASE (database name irrelevant). This will hang trying to lock the same mutex. Since this is the connection holding the metadata lock blocking Connection 2, we have a deadlock. This deadlock would also happen for earlier trees without MDL, but there DROP DATABASE would wait for a table to be removed from the table definition cache. This patch fixes the problem by prohibiting CREATE DATABASE in LOCK TABLES mode. In the example above, this prevents Connection 1 from hanging trying to get the LOCK_mysql_create_db mutex. Note that other commands that use LOCK_mysql_create_db (ALTER/DROP DATABASE) are already prohibited in LOCK TABLES mode. Incompatible change: CREATE DATABASE is now disallowed in LOCK TABLES mode. Test case added to schema.test. mysql-test/t/drop.test: Updates the test for Bug#21216 by swapping the order of CREATE DATABASE and LOCK TABLES. This is now needed as CREATE DATABASE is prohibited in LOCK TABLES mode. mysql-test/t/schema.test: Test case for Bug#49988 added. Also fixes a problem with the test for Bug#48940 where the result would differ for embedded server.
2010-01-12 16:15:21 +01:00
CREATE SCHEMA schema1;
CREATE TABLE schema1.t1 (id INT);
LOCK TABLE schema1.t1 WRITE;
connection con2;
Bug #49988 MDL deadlocks with mysql_create_db, reload_acl_and_cache This was a deadlock between LOCK TABLES/CREATE DATABASE in one connection and DROP DATABASE in another. It only happened if the table locked by LOCK TABLES was in the database to be dropped. The deadlock is similar to the one in Bug#48940, but with LOCK TABLES instead of an active transaction. The order of events needed to trigger the deadlock was: 1) Connection 1 locks table db1.t1 using LOCK TABLES. It will now have a metadata lock on the table name. 2) Connection 2 issues DROP DATABASE db1. This will wait inside the MDL subsystem for the lock on db1.t1 to go away. While waiting, it will hold the LOCK_mysql_create_db mutex. 3) Connection 1 issues CREATE DATABASE (database name irrelevant). This will hang trying to lock the same mutex. Since this is the connection holding the metadata lock blocking Connection 2, we have a deadlock. This deadlock would also happen for earlier trees without MDL, but there DROP DATABASE would wait for a table to be removed from the table definition cache. This patch fixes the problem by prohibiting CREATE DATABASE in LOCK TABLES mode. In the example above, this prevents Connection 1 from hanging trying to get the LOCK_mysql_create_db mutex. Note that other commands that use LOCK_mysql_create_db (ALTER/DROP DATABASE) are already prohibited in LOCK TABLES mode. Incompatible change: CREATE DATABASE is now disallowed in LOCK TABLES mode. Test case added to schema.test. mysql-test/t/drop.test: Updates the test for Bug#21216 by swapping the order of CREATE DATABASE and LOCK TABLES. This is now needed as CREATE DATABASE is prohibited in LOCK TABLES mode. mysql-test/t/schema.test: Test case for Bug#49988 added. Also fixes a problem with the test for Bug#48940 where the result would differ for embedded server.
2010-01-12 16:15:21 +01:00
DROP SCHEMA schema1;
connection default;
Bug #49988 MDL deadlocks with mysql_create_db, reload_acl_and_cache This was a deadlock between LOCK TABLES/CREATE DATABASE in one connection and DROP DATABASE in another. It only happened if the table locked by LOCK TABLES was in the database to be dropped. The deadlock is similar to the one in Bug#48940, but with LOCK TABLES instead of an active transaction. The order of events needed to trigger the deadlock was: 1) Connection 1 locks table db1.t1 using LOCK TABLES. It will now have a metadata lock on the table name. 2) Connection 2 issues DROP DATABASE db1. This will wait inside the MDL subsystem for the lock on db1.t1 to go away. While waiting, it will hold the LOCK_mysql_create_db mutex. 3) Connection 1 issues CREATE DATABASE (database name irrelevant). This will hang trying to lock the same mutex. Since this is the connection holding the metadata lock blocking Connection 2, we have a deadlock. This deadlock would also happen for earlier trees without MDL, but there DROP DATABASE would wait for a table to be removed from the table definition cache. This patch fixes the problem by prohibiting CREATE DATABASE in LOCK TABLES mode. In the example above, this prevents Connection 1 from hanging trying to get the LOCK_mysql_create_db mutex. Note that other commands that use LOCK_mysql_create_db (ALTER/DROP DATABASE) are already prohibited in LOCK TABLES mode. Incompatible change: CREATE DATABASE is now disallowed in LOCK TABLES mode. Test case added to schema.test. mysql-test/t/drop.test: Updates the test for Bug#21216 by swapping the order of CREATE DATABASE and LOCK TABLES. This is now needed as CREATE DATABASE is prohibited in LOCK TABLES mode. mysql-test/t/schema.test: Test case for Bug#49988 added. Also fixes a problem with the test for Bug#48940 where the result would differ for embedded server.
2010-01-12 16:15:21 +01:00
# CREATE SCHEMA used to give a deadlock.
# Now we prohibit CREATE SCHEMA in LOCK TABLES mode.
CREATE SCHEMA IF NOT EXISTS schema1;
ERROR HY000: Can't execute the given command because you have active locked tables or an active transaction
# UNLOCK TABLES so DROP SCHEMA can continue.
UNLOCK TABLES;
connection con2;
connection default;
disconnect con2;
#
# Bug#54360 Deadlock DROP/ALTER/CREATE DATABASE with open HANDLER
#
CREATE DATABASE db1;
CREATE TABLE db1.t1 (a INT);
INSERT INTO db1.t1 VALUES (1), (2);
connect con1, localhost, root;
HANDLER db1.t1 OPEN;
connection default;
# Sending:
DROP DATABASE db1;
connect con2, localhost, root;
connection con1;
CREATE DATABASE db2;
ALTER DATABASE db2 DEFAULT CHARACTER SET utf8;
DROP DATABASE db2;
HANDLER t1 CLOSE;
connection default;
# Reaping: DROP DATABASE db1
disconnect con1;
disconnect con2;
#
# Tests for increased CREATE/ALTER/DROP DATABASE concurrency with
# database name locks.
#
connect con2, localhost, root;
connect con3, localhost, root;
connection default;
CREATE DATABASE db1;
CREATE TABLE db1.t1 (id INT);
START TRANSACTION;
INSERT INTO db1.t1 VALUES (1);
connection con2;
# DROP DATABASE should block due to the active transaction
# Sending:
DROP DATABASE db1;
connection con3;
# But it should still be possible to CREATE/ALTER/DROP other databases.
CREATE DATABASE db2;
ALTER DATABASE db2 DEFAULT CHARACTER SET utf8;
DROP DATABASE db2;
connection default;
# End the transaction so DROP DATABASE db1 can continue
COMMIT;
connection con2;
# Reaping: DROP DATABASE db1
connection default;
disconnect con2;
disconnect con3;