2005-07-27 12:45:06 +02:00
|
|
|
#
|
|
|
|
# Here we collect tests that doesn't work with the embedded server
|
|
|
|
#
|
|
|
|
|
|
|
|
-- source include/not_embedded.inc
|
|
|
|
|
2011-01-07 13:08:05 +01:00
|
|
|
# End of 4.1 tests
|
2005-07-27 12:45:06 +02:00
|
|
|
|
Backport of revno ## 2617.31.1, 2617.31.3, 2617.31.4, 2617.31.5,
2617.31.12, 2617.31.15, 2617.31.15, 2617.31.16, 2617.43.1
- initial changeset that introduced the fix for
Bug#989 and follow up fixes for all test suite failures
introduced in the initial changeset.
------------------------------------------------------------
revno: 2617.31.1
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 4284-6.0
timestamp: Fri 2009-03-06 19:17:00 -0300
message:
Bug#989: If DROP TABLE while there's an active transaction, wrong binlog order
WL#4284: Transactional DDL locking
Currently the MySQL server does not keep metadata locks on
schema objects for the duration of a transaction, thus failing
to guarantee the integrity of the schema objects being used
during the transaction and to protect then from concurrent
DDL operations. This also poses a problem for replication as
a DDL operation might be replicated even thought there are
active transactions using the object being modified.
The solution is to defer the release of metadata locks until
a active transaction is either committed or rolled back. This
prevents other statements from modifying the table for the
entire duration of the transaction. This provides commitment
ordering for guaranteeing serializability across multiple
transactions.
- Incompatible change:
If MySQL's metadata locking system encounters a lock conflict,
the usual schema is to use the try and back-off technique to
avoid deadlocks -- this schema consists in releasing all locks
and trying to acquire them all in one go.
But in a transactional context this algorithm can't be utilized
as its not possible to release locks acquired during the course
of the transaction without breaking the transaction commitments.
To avoid deadlocks in this case, the ER_LOCK_DEADLOCK will be
returned if a lock conflict is encountered during a transaction.
Let's consider an example:
A transaction has two statements that modify table t1, then table
t2, and then commits. The first statement of the transaction will
acquire a shared metadata lock on table t1, and it will be kept
utill COMMIT to ensure serializability.
At the moment when the second statement attempts to acquire a
shared metadata lock on t2, a concurrent ALTER or DROP statement
might have locked t2 exclusively. The prescription of the current
locking protocol is that the acquirer of the shared lock backs off
-- gives up all his current locks and retries. This implies that
the entire multi-statement transaction has to be rolled back.
- Incompatible change:
FLUSH commands such as FLUSH PRIVILEGES and FLUSH TABLES WITH READ
LOCK won't cause locked tables to be implicitly unlocked anymore.
2009-12-05 00:02:48 +01:00
|
|
|
call mtr.add_suppression("Can't open and lock privilege tables: Table 'host' was not locked with LOCK TABLES");
|
|
|
|
|
2009-04-06 13:42:33 +02:00
|
|
|
#
|
|
|
|
# Bug#43835: SHOW VARIABLES does not include 0 for slave_skip_errors
|
|
|
|
#
|
|
|
|
|
|
|
|
SHOW VARIABLES like 'slave_skip_errors';
|
|
|
|
|
2006-08-15 13:10:10 +02:00
|
|
|
# End of 5.1 tests
|
Backport of revno ## 2617.31.1, 2617.31.3, 2617.31.4, 2617.31.5,
2617.31.12, 2617.31.15, 2617.31.15, 2617.31.16, 2617.43.1
- initial changeset that introduced the fix for
Bug#989 and follow up fixes for all test suite failures
introduced in the initial changeset.
------------------------------------------------------------
revno: 2617.31.1
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 4284-6.0
timestamp: Fri 2009-03-06 19:17:00 -0300
message:
Bug#989: If DROP TABLE while there's an active transaction, wrong binlog order
WL#4284: Transactional DDL locking
Currently the MySQL server does not keep metadata locks on
schema objects for the duration of a transaction, thus failing
to guarantee the integrity of the schema objects being used
during the transaction and to protect then from concurrent
DDL operations. This also poses a problem for replication as
a DDL operation might be replicated even thought there are
active transactions using the object being modified.
The solution is to defer the release of metadata locks until
a active transaction is either committed or rolled back. This
prevents other statements from modifying the table for the
entire duration of the transaction. This provides commitment
ordering for guaranteeing serializability across multiple
transactions.
- Incompatible change:
If MySQL's metadata locking system encounters a lock conflict,
the usual schema is to use the try and back-off technique to
avoid deadlocks -- this schema consists in releasing all locks
and trying to acquire them all in one go.
But in a transactional context this algorithm can't be utilized
as its not possible to release locks acquired during the course
of the transaction without breaking the transaction commitments.
To avoid deadlocks in this case, the ER_LOCK_DEADLOCK will be
returned if a lock conflict is encountered during a transaction.
Let's consider an example:
A transaction has two statements that modify table t1, then table
t2, and then commits. The first statement of the transaction will
acquire a shared metadata lock on table t1, and it will be kept
utill COMMIT to ensure serializability.
At the moment when the second statement attempts to acquire a
shared metadata lock on t2, a concurrent ALTER or DROP statement
might have locked t2 exclusively. The prescription of the current
locking protocol is that the acquirer of the shared lock backs off
-- gives up all his current locks and retries. This implies that
the entire multi-statement transaction has to be rolled back.
- Incompatible change:
FLUSH commands such as FLUSH PRIVILEGES and FLUSH TABLES WITH READ
LOCK won't cause locked tables to be implicitly unlocked anymore.
2009-12-05 00:02:48 +01:00
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # WL#4284: Transactional DDL locking
|
|
|
|
--echo #
|
|
|
|
--echo # FLUSH PRIVILEGES should not implicitly unlock locked tables.
|
|
|
|
--echo #
|
|
|
|
--disable_warnings
|
2011-01-07 13:08:05 +01:00
|
|
|
DROP TABLE IF EXISTS t1;
|
Backport of revno ## 2617.31.1, 2617.31.3, 2617.31.4, 2617.31.5,
2617.31.12, 2617.31.15, 2617.31.15, 2617.31.16, 2617.43.1
- initial changeset that introduced the fix for
Bug#989 and follow up fixes for all test suite failures
introduced in the initial changeset.
------------------------------------------------------------
revno: 2617.31.1
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 4284-6.0
timestamp: Fri 2009-03-06 19:17:00 -0300
message:
Bug#989: If DROP TABLE while there's an active transaction, wrong binlog order
WL#4284: Transactional DDL locking
Currently the MySQL server does not keep metadata locks on
schema objects for the duration of a transaction, thus failing
to guarantee the integrity of the schema objects being used
during the transaction and to protect then from concurrent
DDL operations. This also poses a problem for replication as
a DDL operation might be replicated even thought there are
active transactions using the object being modified.
The solution is to defer the release of metadata locks until
a active transaction is either committed or rolled back. This
prevents other statements from modifying the table for the
entire duration of the transaction. This provides commitment
ordering for guaranteeing serializability across multiple
transactions.
- Incompatible change:
If MySQL's metadata locking system encounters a lock conflict,
the usual schema is to use the try and back-off technique to
avoid deadlocks -- this schema consists in releasing all locks
and trying to acquire them all in one go.
But in a transactional context this algorithm can't be utilized
as its not possible to release locks acquired during the course
of the transaction without breaking the transaction commitments.
To avoid deadlocks in this case, the ER_LOCK_DEADLOCK will be
returned if a lock conflict is encountered during a transaction.
Let's consider an example:
A transaction has two statements that modify table t1, then table
t2, and then commits. The first statement of the transaction will
acquire a shared metadata lock on table t1, and it will be kept
utill COMMIT to ensure serializability.
At the moment when the second statement attempts to acquire a
shared metadata lock on t2, a concurrent ALTER or DROP statement
might have locked t2 exclusively. The prescription of the current
locking protocol is that the acquirer of the shared lock backs off
-- gives up all his current locks and retries. This implies that
the entire multi-statement transaction has to be rolled back.
- Incompatible change:
FLUSH commands such as FLUSH PRIVILEGES and FLUSH TABLES WITH READ
LOCK won't cause locked tables to be implicitly unlocked anymore.
2009-12-05 00:02:48 +01:00
|
|
|
--enable_warnings
|
2011-01-07 13:08:05 +01:00
|
|
|
CREATE TABLE t1 (c1 INT);
|
|
|
|
LOCK TABLES t1 READ;
|
Backport of revno ## 2617.31.1, 2617.31.3, 2617.31.4, 2617.31.5,
2617.31.12, 2617.31.15, 2617.31.15, 2617.31.16, 2617.43.1
- initial changeset that introduced the fix for
Bug#989 and follow up fixes for all test suite failures
introduced in the initial changeset.
------------------------------------------------------------
revno: 2617.31.1
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 4284-6.0
timestamp: Fri 2009-03-06 19:17:00 -0300
message:
Bug#989: If DROP TABLE while there's an active transaction, wrong binlog order
WL#4284: Transactional DDL locking
Currently the MySQL server does not keep metadata locks on
schema objects for the duration of a transaction, thus failing
to guarantee the integrity of the schema objects being used
during the transaction and to protect then from concurrent
DDL operations. This also poses a problem for replication as
a DDL operation might be replicated even thought there are
active transactions using the object being modified.
The solution is to defer the release of metadata locks until
a active transaction is either committed or rolled back. This
prevents other statements from modifying the table for the
entire duration of the transaction. This provides commitment
ordering for guaranteeing serializability across multiple
transactions.
- Incompatible change:
If MySQL's metadata locking system encounters a lock conflict,
the usual schema is to use the try and back-off technique to
avoid deadlocks -- this schema consists in releasing all locks
and trying to acquire them all in one go.
But in a transactional context this algorithm can't be utilized
as its not possible to release locks acquired during the course
of the transaction without breaking the transaction commitments.
To avoid deadlocks in this case, the ER_LOCK_DEADLOCK will be
returned if a lock conflict is encountered during a transaction.
Let's consider an example:
A transaction has two statements that modify table t1, then table
t2, and then commits. The first statement of the transaction will
acquire a shared metadata lock on table t1, and it will be kept
utill COMMIT to ensure serializability.
At the moment when the second statement attempts to acquire a
shared metadata lock on t2, a concurrent ALTER or DROP statement
might have locked t2 exclusively. The prescription of the current
locking protocol is that the acquirer of the shared lock backs off
-- gives up all his current locks and retries. This implies that
the entire multi-statement transaction has to be rolled back.
- Incompatible change:
FLUSH commands such as FLUSH PRIVILEGES and FLUSH TABLES WITH READ
LOCK won't cause locked tables to be implicitly unlocked anymore.
2009-12-05 00:02:48 +01:00
|
|
|
--error ER_TABLE_NOT_LOCKED
|
2011-01-07 13:08:05 +01:00
|
|
|
FLUSH PRIVILEGES;
|
|
|
|
UNLOCK TABLES;
|
|
|
|
DROP TABLE t1;
|
2010-11-15 16:18:04 +01:00
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Bug#54812: assert in Diagnostics_area::set_ok_status during EXPLAIN
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
CREATE USER nopriv_user@localhost;
|
|
|
|
|
|
|
|
connection default;
|
|
|
|
--echo connection: default
|
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
DROP TABLE IF EXISTS t1,t2,t3;
|
|
|
|
DROP FUNCTION IF EXISTS f;
|
|
|
|
--enable_warnings
|
|
|
|
|
|
|
|
CREATE TABLE t1 (key1 INT PRIMARY KEY);
|
|
|
|
CREATE TABLE t2 (key2 INT);
|
|
|
|
INSERT INTO t1 VALUES (1),(2);
|
|
|
|
|
|
|
|
CREATE FUNCTION f() RETURNS INT RETURN 1;
|
|
|
|
|
|
|
|
GRANT FILE ON *.* TO 'nopriv_user'@'localhost';
|
|
|
|
|
|
|
|
FLUSH PRIVILEGES;
|
|
|
|
|
|
|
|
connect (con1,localhost,nopriv_user,,);
|
|
|
|
connection con1;
|
|
|
|
--echo connection: con1
|
|
|
|
|
2011-01-07 13:08:05 +01:00
|
|
|
let outfile=$MYSQLTEST_VARDIR/tmp/mytest;
|
|
|
|
--error 0,1
|
|
|
|
--remove_file $outfile
|
|
|
|
--replace_result $outfile <outfile>
|
2010-11-15 16:18:04 +01:00
|
|
|
--error ER_PROCACCESS_DENIED_ERROR
|
2011-01-07 13:08:05 +01:00
|
|
|
eval SELECT MAX(key1) FROM t1 WHERE f() < 1 INTO OUTFILE '$outfile';
|
|
|
|
# A removal of the outfile is necessary, at least today (2010-12-07), because
|
|
|
|
# the outfile is created even if the SELECT statement fails.
|
|
|
|
# If the server is improved in the future this may not happen.
|
|
|
|
# ==> Do not fail if the outfile does not exist.
|
|
|
|
--error 0,1
|
|
|
|
--remove_file $outfile
|
2010-11-15 16:18:04 +01:00
|
|
|
|
|
|
|
--error ER_PROCACCESS_DENIED_ERROR
|
|
|
|
INSERT INTO t2 SELECT MAX(key1) FROM t1 WHERE f() < 1;
|
|
|
|
|
|
|
|
--error ER_PROCACCESS_DENIED_ERROR
|
|
|
|
SELECT MAX(key1) INTO @dummy FROM t1 WHERE f() < 1;
|
|
|
|
|
|
|
|
--error ER_PROCACCESS_DENIED_ERROR
|
|
|
|
CREATE TABLE t3 (i INT) AS SELECT MAX(key1) FROM t1 WHERE f() < 1;
|
|
|
|
|
|
|
|
disconnect con1;
|
|
|
|
--source include/wait_until_disconnected.inc
|
|
|
|
|
|
|
|
connection default;
|
|
|
|
--echo connection: default
|
|
|
|
|
|
|
|
DROP TABLE t1,t2;
|
|
|
|
DROP FUNCTION f;
|
|
|
|
DROP USER nopriv_user@localhost;
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # End Bug#54812
|
|
|
|
--echo #
|