diff options
Diffstat (limited to 'mysql-test/r/lock_sync.result')
| -rw-r--r-- | mysql-test/r/lock_sync.result | 158 |
1 files changed, 123 insertions, 35 deletions
diff --git a/mysql-test/r/lock_sync.result b/mysql-test/r/lock_sync.result index 219cc08342e..f075262c3db 100644 --- a/mysql-test/r/lock_sync.result +++ b/mysql-test/r/lock_sync.result @@ -23,6 +23,9 @@ select @@global.concurrent_insert; ALWAYS # Prepare playground by creating tables, views, # routines and triggers used in tests. +connect con1, localhost, root,,; +connect con2, localhost, root,,; +connection default; drop table if exists t0, t1, t2, t3, t4, t5; drop view if exists v1, v2; drop procedure if exists p1; @@ -201,7 +204,7 @@ end| # Set common variables to be used by the scripts # called below. # -# Switch to connection 'con1'. +connection con1; # Cache all functions used in the tests below so statements # calling them won't need to open and lock mysql.proc table # and we can assume that each statement locks its tables @@ -226,7 +229,7 @@ show create function f14; show create function f15; show create function f16; show create function f17; -# Switch back to connection 'default'. +connection default; # # 1. Statements that read tables and do not use subqueries. # @@ -236,6 +239,7 @@ show create function f17; # No locks are necessary as this statement won't be written # to the binary log and thanks to how MyISAM works SELECT # will see version of the table prior to concurrent insert. +connection default; Success: 'select * from t1' allows concurrent inserts into 't1'. # # 1.2 Multi-UPDATE statement. @@ -243,11 +247,13 @@ Success: 'select * from t1' allows concurrent inserts into 't1'. # Has to take shared locks on rows in the table being read as this # statement will be written to the binary log and therefore should # be serialized with concurrent statements. +connection default; Success: 'update t2, t1 set j= j - 1 where i = j' doesn't allow concurrent inserts into 't1'. # # 1.3 Multi-DELETE statement. # # The above is true for this statement as well. +connection default; Success: 'delete t2 from t1, t2 where i = j' doesn't allow concurrent inserts into 't1'. # # 1.4 DESCRIBE statement. @@ -256,20 +262,20 @@ Success: 'delete t2 from t1, t2 where i = j' doesn't allow concurrent inserts in # target table and thus does not take any lock on it. # We check this for completeness of coverage. lock table t1 write; -# Switching to connection 'con1'. +connection con1; # This statement should not be blocked. describe t1; -# Switching to connection 'default'. +connection default; unlock tables; # # 1.5 SHOW statements. # # The above is true for SHOW statements as well. lock table t1 write; -# Switching to connection 'con1'. +connection con1; # These statements should not be blocked. show keys from t1; -# Switching to connection 'default'. +connection default; unlock tables; # # 2. Statements which read tables through subqueries. @@ -280,6 +286,7 @@ unlock tables; # A strong lock is not necessary as this statement is not # written to the binary log as a whole (it is written # statement-by-statement). +connection default; Success: 'call p1((select i + 5 from t1 where i = 1))' allows concurrent inserts into 't1'. # # 2.2 CREATE TABLE with a subquery. @@ -287,24 +294,29 @@ Success: 'call p1((select i + 5 from t1 where i = 1))' allows concurrent inserts # Has to take a strong lock on the table being read as # this statement is written to the binary log and therefore # should be serialized with concurrent statements. +connection default; Success: 'create table t0 select * from t1' doesn't allow concurrent inserts into 't1'. drop table t0; +connection default; Success: 'create table t0 select j from t2 where j in (select i from t1)' doesn't allow concurrent inserts into 't1'. drop table t0; # # 2.3 DELETE with a subquery. # # The above is true for this statement as well. +connection default; Success: 'delete from t2 where j in (select i from t1)' doesn't allow concurrent inserts into 't1'. # # 2.4 MULTI-DELETE with a subquery. # # Same is true for this statement as well. +connection default; Success: 'delete t2 from t3, t2 where k = j and j in (select i from t1)' doesn't allow concurrent inserts into 't1'. # # 2.5 DO with a subquery. # # A strong lock is not necessary as it is not logged. +connection default; Success: 'do (select i from t1 where i = 1)' allows concurrent inserts into 't1'. # # 2.6 INSERT with a subquery. @@ -312,18 +324,23 @@ Success: 'do (select i from t1 where i = 1)' allows concurrent inserts into 't1' # Has to take a strong lock on the table being read as # this statement is written to the binary log and therefore # should be serialized with concurrent inserts. +connection default; Success: 'insert into t2 select i+5 from t1' doesn't allow concurrent inserts into 't1'. +connection default; Success: 'insert into t2 values ((select i+5 from t1 where i = 4))' doesn't allow concurrent inserts into 't1'. # # 2.7 LOAD DATA with a subquery. # # The above is true for this statement as well. +connection default; Success: 'load data infile '../../std_data/rpl_loaddata.dat' into table t2 (@a, @b) set j= @b + (select i from t1 where i = 1)' doesn't allow concurrent inserts into 't1'. # # 2.8 REPLACE with a subquery. # # Same is true for this statement as well. +connection default; Success: 'replace into t2 select i+5 from t1' doesn't allow concurrent inserts into 't1'. +connection default; Success: 'replace into t2 values ((select i+5 from t1 where i = 4))' doesn't allow concurrent inserts into 't1'. # # 2.9 SELECT with a subquery. @@ -331,17 +348,21 @@ Success: 'replace into t2 values ((select i+5 from t1 where i = 4))' doesn't all # Strong locks are not necessary as this statement is not written # to the binary log and thanks to how MyISAM works this statement # sees a version of the table prior to the concurrent insert. +connection default; Success: 'select * from t2 where j in (select i from t1)' allows concurrent inserts into 't1'. # # 2.10 SET with a subquery. # # The same is true for this statement as well. +connection default; Success: 'set @a:= (select i from t1 where i = 1)' allows concurrent inserts into 't1'. # # 2.11 SHOW with a subquery. # # And for this statement too. +connection default; Success: 'show tables from test where Tables_in_test = 't2' and (select i from t1 where i = 1)' allows concurrent inserts into 't1'. +connection default; Success: 'show columns from t2 where (select i from t1 where i = 1)' allows concurrent inserts into 't1'. # # 2.12 UPDATE with a subquery. @@ -349,11 +370,13 @@ Success: 'show columns from t2 where (select i from t1 where i = 1)' allows conc # Has to take a strong lock on the table being read as # this statement is written to the binary log and therefore # should be serialized with concurrent inserts. +connection default; Success: 'update t2 set j= j-10 where j in (select i from t1)' doesn't allow concurrent inserts into 't1'. # # 2.13 MULTI-UPDATE with a subquery. # # Same is true for this statement as well. +connection default; Success: 'update t2, t3 set j= j -10 where j=k and j in (select i from t1)' doesn't allow concurrent inserts into 't1'. # # 3. Statements which read tables through a view. @@ -364,9 +387,13 @@ Success: 'update t2, t3 set j= j -10 where j=k and j in (select i from t1)' does # Since this statement is not written to the binary log and # an old version of the table is accessible thanks to how MyISAM # handles concurrent insert, no locking is necessary. +connection default; Success: 'select * from v1' allows concurrent inserts into 't1'. +connection default; Success: 'select * from v2' allows concurrent inserts into 't1'. +connection default; Success: 'select * from t2 where j in (select i from v1)' allows concurrent inserts into 't1'. +connection default; Success: 'select * from t3 where k in (select j from v2)' allows concurrent inserts into 't1'. # # 3.2 Statements which modify a table and use views. @@ -374,9 +401,13 @@ Success: 'select * from t3 where k in (select j from v2)' allows concurrent inse # Since such statements are going to be written to the binary # log they need to be serialized against concurrent statements # and therefore should take strong locks on the data read. +connection default; Success: 'update t2 set j= j-10 where j in (select i from v1)' doesn't allow concurrent inserts into 't1'. +connection default; Success: 'update t3 set k= k-10 where k in (select j from v2)' doesn't allow concurrent inserts into 't1'. +connection default; Success: 'update t2, v1 set j= j-10 where j = i' doesn't allow concurrent inserts into 't1'. +connection default; Success: 'update v2 set j= j-10 where j = 3' doesn't allow concurrent inserts into 't1'. # # 4. Statements which read tables through stored functions. @@ -388,7 +419,9 @@ Success: 'update v2 set j= j-10 where j = 3' doesn't allow concurrent inserts in # There is no need to take strong locks on the table # being selected from in SF as the call to such function # won't get into the binary log. +connection default; Success: 'select f1()' allows concurrent inserts into 't1'. +connection default; Success: 'set @a:= f1()' allows concurrent inserts into 't1'. # # 4.2 INSERT (or other statement which modifies data) with @@ -399,6 +432,7 @@ Success: 'set @a:= f1()' allows concurrent inserts into 't1'. # be serialized with concurrent statements affecting the data # it uses. Therefore it should take strong lock on the data # it reads. +connection default; Success: 'insert into t2 values (f1() + 5)' doesn't allow concurrent inserts into 't1'. # # 4.3 SELECT/SET with a stored function which @@ -408,7 +442,9 @@ Success: 'insert into t2 values (f1() + 5)' doesn't allow concurrent inserts int # it should be serialized with concurrent statements affecting # the data it uses. Hence, a strong lock on the data read # should be taken. +connection default; Success: 'select f2()' doesn't allow concurrent inserts into 't1'. +connection default; Success: 'set @a:= f2()' doesn't allow concurrent inserts into 't1'. # # 4.4. SELECT/SET with a stored function which does not @@ -417,9 +453,13 @@ Success: 'set @a:= f2()' doesn't allow concurrent inserts into 't1'. # # Call to this function won't get to the # binary log and thus no strong lock is needed. +connection default; Success: 'select f3()' allows concurrent inserts into 't1'. +connection default; Success: 'set @a:= f3()' allows concurrent inserts into 't1'. +connection default; Success: 'select f4()' allows concurrent inserts into 't1'. +connection default; Success: 'set @a:= f4()' allows concurrent inserts into 't1'. # # 4.5. INSERT (or other statement which modifies data) with @@ -431,7 +471,9 @@ Success: 'set @a:= f4()' allows concurrent inserts into 't1'. # be serialized with concurrent statements affecting data it # uses. Therefore it should take a strong lock on the data # it reads. +connection default; Success: 'insert into t2 values (f3() + 5)' doesn't allow concurrent inserts into 't1'. +connection default; Success: 'insert into t2 values (f4() + 6)' doesn't allow concurrent inserts into 't1'. # # 4.6 SELECT/SET which uses a stored function with @@ -440,7 +482,9 @@ Success: 'insert into t2 values (f4() + 6)' doesn't allow concurrent inserts int # Since call to such function is written to the binary log # it should be serialized with concurrent statements. # Hence reads should take a strong lock. +connection default; Success: 'select f5()' doesn't allow concurrent inserts into 't1'. +connection default; Success: 'set @a:= f5()' doesn't allow concurrent inserts into 't1'. # # 4.7 SELECT/SET which uses a stored function which @@ -450,9 +494,13 @@ Success: 'set @a:= f5()' doesn't allow concurrent inserts into 't1'. # Calls to such functions won't get into # the binary log and thus don't need strong # locks. +connection default; Success: 'select f6()' allows concurrent inserts into 't1'. +connection default; Success: 'set @a:= f6()' allows concurrent inserts into 't1'. +connection default; Success: 'select f7()' allows concurrent inserts into 't1'. +connection default; Success: 'set @a:= f7()' allows concurrent inserts into 't1'. # # 4.8 INSERT which uses stored function which @@ -463,7 +511,9 @@ Success: 'set @a:= f7()' allows concurrent inserts into 't1'. # should be serialized with concurrent statements affecting # the data it uses. Therefore it should take a strong lock on # the table it reads. +connection default; Success: 'insert into t3 values (f6() + 5)' doesn't allow concurrent inserts into 't1'. +connection default; Success: 'insert into t3 values (f7() + 5)' doesn't allow concurrent inserts into 't1'. # # 4.9 SELECT which uses a stored function which @@ -472,7 +522,9 @@ Success: 'insert into t3 values (f7() + 5)' doesn't allow concurrent inserts int # Since a call to such function is written to the binary log # it should be serialized with concurrent statements. # Hence, reads should take strong locks. +connection default; Success: 'select f8()' doesn't allow concurrent inserts into 't1'. +connection default; Success: 'select f9()' doesn't allow concurrent inserts into 't1'. # # 4.10 SELECT which uses a stored function which doesn't modify @@ -481,6 +533,7 @@ Success: 'select f9()' doesn't allow concurrent inserts into 't1'. # # Calls to such functions won't get into the binary # log and thus don't need to acquire strong locks. +connection default; Success: 'select f10()' allows concurrent inserts into 't1'. # # 4.11 INSERT which uses a stored function which doesn't modify @@ -490,6 +543,7 @@ Success: 'select f10()' allows concurrent inserts into 't1'. # Since such statement is written to the binary log, it should # be serialized with concurrent statements affecting the data it # uses. Therefore it should take strong locks on data it reads. +connection default; Success: 'insert into t2 values (f10() + 5)' doesn't allow concurrent inserts into 't1'. # # 4.12 SELECT which uses a stored function which modifies @@ -499,6 +553,7 @@ Success: 'insert into t2 values (f10() + 5)' doesn't allow concurrent inserts in # Since a call to such function is written to the binary log # it should be serialized from concurrent statements. # Hence, read should take a strong lock. +connection default; Success: 'select f11()' doesn't allow concurrent inserts into 't1'. # # 4.13 SELECT that reads a table through a subquery passed @@ -509,6 +564,7 @@ Success: 'select f11()' doesn't allow concurrent inserts into 't1'. # binary log, values of its parameters are written as literals. # So there is no need to acquire strong locks for tables used in # the subquery. +connection default; Success: 'select f12((select i+10 from t1 where i=1))' allows concurrent inserts into 't1'. # # 4.14 INSERT that reads a table via a subquery passed @@ -518,6 +574,7 @@ Success: 'select f12((select i+10 from t1 where i=1))' allows concurrent inserts # Since this statement is written to the binary log it should # be serialized with concurrent statements affecting the data it # uses. Therefore it should take strong locks on the data it reads. +connection default; Success: 'insert into t2 values (f13((select i+10 from t1 where i=1)))' doesn't allow concurrent inserts into 't1'. # # 4.15 SELECT/SET with a stored function which @@ -527,7 +584,9 @@ Success: 'insert into t2 values (f13((select i+10 from t1 where i=1)))' doesn't # Since this statement is written to the binary log it should # be serialized with concurrent statements affecting the data it # uses. Therefore it should take strong locks on the data it reads. +connection default; Success: 'select f16()' doesn't allow concurrent inserts into 't1'. +connection default; Success: 'set @a:= f16()' doesn't allow concurrent inserts into 't1'. # # 4.16 SELECT/SET with a stored function which call procedure @@ -537,7 +596,9 @@ Success: 'set @a:= f16()' doesn't allow concurrent inserts into 't1'. # Since this statement is written to the binary log it should # be serialized with concurrent statements affecting the data it # uses. Therefore it should take strong locks on the data it reads. +connection default; Success: 'select f17()' doesn't allow concurrent inserts into 't1'. +connection default; Success: 'set @a:= f17()' doesn't allow concurrent inserts into 't1'. # # 5. Statements that read tables through stored procedures. @@ -548,6 +609,7 @@ Success: 'set @a:= f17()' doesn't allow concurrent inserts into 't1'. # Since neither this statement nor its components are # written to the binary log, there is no need to take # strong locks on the data it reads. +connection default; Success: 'call p2(@a)' allows concurrent inserts into 't1'. # # 5.2 Function that modifies data and uses CALL, @@ -556,6 +618,7 @@ Success: 'call p2(@a)' allows concurrent inserts into 't1'. # Since a call to such function is written to the binary # log, it should be serialized with concurrent statements. # Hence, in this case reads should take strong locks on data. +connection default; Success: 'select f14()' doesn't allow concurrent inserts into 't1'. # # 5.3 SELECT that calls a function that doesn't modify data and @@ -563,6 +626,7 @@ Success: 'select f14()' doesn't allow concurrent inserts into 't1'. # # Calls to such functions won't get into the binary # log and thus don't need to acquire strong locks. +connection default; Success: 'select f15()' allows concurrent inserts into 't1'. # # 5.4 INSERT which calls function which doesn't modify data and @@ -571,6 +635,7 @@ Success: 'select f15()' allows concurrent inserts into 't1'. # Since such statement is written to the binary log it should # be serialized with concurrent statements affecting data it # uses. Therefore it should take strong locks on data it reads. +connection default; Success: 'insert into t2 values (f15()+5)' doesn't allow concurrent inserts into 't1'. # # 6. Statements that use triggers. @@ -582,30 +647,35 @@ Success: 'insert into t2 values (f15()+5)' doesn't allow concurrent inserts into # be serialized with concurrent statements affecting the data # it uses. Therefore, it should take strong locks on the data # it reads. +connection default; Success: 'insert into t4 values (2)' doesn't allow concurrent inserts into 't1'. # # 6.2 Statement invoking a trigger that reads table through # a subquery in a control construct. # # The above is true for this statement as well. +connection default; Success: 'update t4 set l= 2 where l = 1' doesn't allow concurrent inserts into 't1'. # # 6.3 Statement invoking a trigger that reads a table through # a view. # # And for this statement. +connection default; Success: 'delete from t4 where l = 1' doesn't allow concurrent inserts into 't1'. # # 6.4 Statement invoking a trigger that reads a table through # a stored function. # # And for this statement. +connection default; Success: 'insert into t5 values (2)' doesn't allow concurrent inserts into 't1'. # # 6.5 Statement invoking a trigger that reads a table through # stored procedure. # # And for this statement. +connection default; Success: 'update t5 set l= 2 where l = 1' doesn't allow concurrent inserts into 't1'. # Clean-up. drop function f1; @@ -630,6 +700,8 @@ drop procedure p1; drop procedure p2; drop procedure p3; drop table t1, t2, t3, t4, t5; +disconnect con1; +disconnect con2; set @@global.concurrent_insert= @old_concurrent_insert; # # Test for bug #45143 "All connections hang on concurrent ALTER TABLE". @@ -641,6 +713,10 @@ set @@global.concurrent_insert= @old_concurrent_insert; drop table if exists t1; drop view if exists v1; # Create auxiliary connections used through the test. +connect con_bug45143_1,localhost,root,,test,,; +connect con_bug45143_3,localhost,root,,test,,; +connect con_bug45143_2,localhost,root,,test,,; +connection default; # Reset DEBUG_SYNC facility before using it. set debug_sync= 'RESET'; # Turn off logging so calls to locking subsystem performed @@ -657,10 +733,10 @@ insert into t1 values (1); select get_lock("lock_bug45143_wait", 0); get_lock("lock_bug45143_wait", 0) 1 -# Switch to connection 'con_bug45143_1'. +connection con_bug45143_1; # Sending: insert into t1 values (get_lock("lock_bug45143_wait", 100));; -# Switch to connection 'con_bug45143_2'. +connection con_bug45143_2; # Wait until the above INSERT takes TL_WRITE_ALLOW_WRITE lock on 't1' # and then gets blocked on user lock 'lock_bug45143_wait'. # Ensure that upcoming SELECT waits after acquiring TL_WRITE_ALLOW_WRITE @@ -668,13 +744,13 @@ insert into t1 values (get_lock("lock_bug45143_wait", 100));; set debug_sync='thr_multi_lock_after_thr_lock SIGNAL parked WAIT_FOR go'; # Sending: select count(*) > 0 from t1 as a, t1 as b for update;; -# Switch to connection 'con_bug45143_3'. +connection con_bug45143_3; # Wait until the above SELECT ... FOR UPDATE is blocked after # acquiring lock for the the first instance of 't1'. set debug_sync= 'now WAIT_FOR parked'; # Send LOCK TABLE statement which will try to get TL_WRITE lock on 't1': lock table v1 write;; -# Switch to connection 'default'. +connection default; # Wait until this LOCK TABLES statement starts waiting for table lock. # Allow SELECT ... FOR UPDATE to resume. # Since it already has TL_WRITE_ALLOW_WRITE lock on the first instance @@ -682,25 +758,28 @@ lock table v1 write;; # waiting, even although there is another thread which has such lock # on this table and also there is a thread waiting for a TL_WRITE on it. set debug_sync= 'now SIGNAL go'; -# Switch to connection 'con_bug45143_2'. +connection con_bug45143_2; # Reap SELECT ... FOR UPDATE count(*) > 0 1 -# Switch to connection 'default'. +connection default; # Resume execution of the INSERT statement. select release_lock("lock_bug45143_wait"); release_lock("lock_bug45143_wait") 1 -# Switch to connection 'con_bug45143_1'. +connection con_bug45143_1; # Reap INSERT statement. # In Statement and Mixed replication mode we get here "Unsafe # for binlog" warnings. In row mode there are no warnings. # Hide the discrepancy. -# Switch to connection 'con_bug45143_3'. +connection con_bug45143_3; # Reap LOCK TABLES statement. unlock tables; -# Switch to connection 'default'. +connection default; # Do clean-up. +disconnect con_bug45143_1; +disconnect con_bug45143_2; +disconnect con_bug45143_3; set debug_sync= 'RESET'; set @@global.general_log= @old_general_log; drop view v1; @@ -711,38 +790,40 @@ drop table t1; DROP TABLE IF EXISTS t1, t2; CREATE TABLE t1(id INT); CREATE TABLE t2(id INT); -# Connection con2 +connect con2, localhost, root; START TRANSACTION; SELECT * FROM t1; id -# Connection default +connection default; # Sending: ALTER TABLE t1 ADD COLUMN j INT; -# Connection con2 +connection con2; # This used to cause a deadlock. INSERT INTO t2 SELECT * FROM t1; COMMIT; -# Connection default +connection default; # Reaping ALTER TABLE t1 ADD COLUMN j INT DROP TABLE t1, t2; +disconnect con2; # # Bug#51391 Deadlock involving events during rqg_info_schema test # CREATE EVENT e1 ON SCHEDULE EVERY 5 HOUR DO SELECT 1; CREATE EVENT e2 ON SCHEDULE EVERY 5 HOUR DO SELECT 2; -# Connection con1 +connect con1, localhost, root; SET DEBUG_SYNC="before_lock_tables_takes_lock SIGNAL drop WAIT_FOR query"; # Sending: DROP EVENT e1;; -# Connection default +connection default; SET DEBUG_SYNC="now WAIT_FOR drop"; SELECT name FROM mysql.event, INFORMATION_SCHEMA.GLOBAL_VARIABLES WHERE definer = VARIABLE_VALUE; name SET DEBUG_SYNC="now SIGNAL query"; -# Connection con1 +connection con1; # Reaping: DROP EVENT t1 -# Connection default +disconnect con1; +connection default; DROP EVENT e2; SET DEBUG_SYNC="RESET"; # @@ -752,20 +833,22 @@ SET DEBUG_SYNC="RESET"; DROP TABLE IF EXISTS t1; CREATE TABLE t1(a INT) engine=InnoDB; INSERT INTO t1 VALUES (1), (2); -# Connection con1 +connect con1, localhost, root; +connect con2, localhost, root; +connection con1; SET SESSION lock_wait_timeout= 1; SET DEBUG_SYNC= 'ha_admin_open_ltable SIGNAL opti_recreate WAIT_FOR opti_analyze'; # Sending: OPTIMIZE TABLE t1; -# Connection con2 +connection con2; SET DEBUG_SYNC= 'now WAIT_FOR opti_recreate'; SET DEBUG_SYNC= 'after_lock_tables_takes_lock SIGNAL thrlock WAIT_FOR release_thrlock'; # Sending: INSERT INTO t1 VALUES (3); -# Connection default +connection default; SET DEBUG_SYNC= 'now WAIT_FOR thrlock'; SET DEBUG_SYNC= 'now SIGNAL opti_analyze'; -# Connection con1 +connection con1; # Reaping: OPTIMIZE TABLE t1 Table Op Msg_type Msg_text test.t1 optimize note Table does not support optimize, doing recreate + analyze instead @@ -774,9 +857,11 @@ test.t1 optimize status Operation failed Warnings: Error 1205 Lock wait timeout exceeded; try restarting transaction SET DEBUG_SYNC= 'now SIGNAL release_thrlock'; -# Connection con2 +disconnect con1; +connection con2; # Reaping: INSERT INTO t1 VALUES (3) -# Connection default +disconnect con2; +connection default; DROP TABLE t1; SET DEBUG_SYNC= 'RESET'; # @@ -789,28 +874,31 @@ CREATE TABLE t1(a INT); CREATE FUNCTION f1() RETURNS INTEGER RETURN 1; CREATE VIEW v1 AS SELECT * FROM t1 WHERE f1() = 1; DROP FUNCTION f1; -# Connection con1 +connect con2, localhost, root; +connect con1, localhost, root; SET DEBUG_SYNC= 'open_tables_after_open_and_process_table SIGNAL opened WAIT_FOR dropped EXECUTE 2'; # Sending: SHOW CREATE VIEW v1; -# Connection con2 +connection con2; SET DEBUG_SYNC= 'now WAIT_FOR opened'; SET DEBUG_SYNC= 'now SIGNAL dropped'; SET DEBUG_SYNC= 'now WAIT_FOR opened'; # Sending: FLUSH TABLES; -# Connection default +connection default; # Waiting for FLUSH TABLES to be blocked. SET DEBUG_SYNC= 'now SIGNAL dropped'; -# Connection con1 +connection con1; # Reaping: SHOW CREATE VIEW v1 View Create View character_set_client collation_connection v1 CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `v1` AS select `t1`.`a` AS `a` from `t1` where (`f1`() = 1) latin1 latin1_swedish_ci Warnings: Warning 1356 View 'test.v1' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them -# Connection con2 +connection con2; # Reaping: FLUSH TABLES -# Connection default +connection default; SET DEBUG_SYNC= 'RESET'; DROP VIEW v1; DROP TABLE t1; +disconnect con1; +disconnect con2; |