From 28ae1da5727c472fb2dc2c730982aa25e6959514 Mon Sep 17 00:00:00 2001 From: Vasil Dimov Date: Tue, 17 Aug 2010 22:37:18 +0300 Subject: Disable all innodb_plugin tests on Solaris until the problem is resolved. Track this via: Bug#56063 InnoDB Plugin mysql-tests fail on Solaris --- mysql-test/collections/default.experimental | 2 ++ 1 file changed, 2 insertions(+) (limited to 'mysql-test') diff --git a/mysql-test/collections/default.experimental b/mysql-test/collections/default.experimental index f84337660ea..6d29134316d 100644 --- a/mysql-test/collections/default.experimental +++ b/mysql-test/collections/default.experimental @@ -12,6 +12,8 @@ funcs_1.ndb* # joro : NDB tests marked as experiment funcs_2.ndb_charset # joro : NDB tests marked as experimental as agreed with bochklin +innodb_plugin.* @solaris # Bug#56063 InnoDB Plugin mysql-tests fail on Solaris + main.ctype_gbk_binlog @solaris # Bug#46010: main.ctype_gbk_binlog fails sporadically : Table 't2' already exists main.func_str @solaris # joro: Bug#40928 main.plugin_load @solaris # Bug#42144 -- cgit v1.2.1 From 8599cf878cae05c557c71348c76ceb9b61d4d09f Mon Sep 17 00:00:00 2001 From: Mattias Jonsson Date: Fri, 20 Aug 2010 21:17:51 +0200 Subject: post push test fix --- mysql-test/t/partition_not_blackhole.test | 1 + 1 file changed, 1 insertion(+) (limited to 'mysql-test') diff --git a/mysql-test/t/partition_not_blackhole.test b/mysql-test/t/partition_not_blackhole.test index 222c1bb091e..7352aeaa230 100644 --- a/mysql-test/t/partition_not_blackhole.test +++ b/mysql-test/t/partition_not_blackhole.test @@ -16,6 +16,7 @@ let $MYSQLD_DATADIR= `SELECT @@datadir`; --copy_file std_data/parts/t1_blackhole.frm $MYSQLD_DATADIR/test/t1.frm --copy_file std_data/parts/t1_blackhole.par $MYSQLD_DATADIR/test/t1.par SHOW TABLES; +--replace_result $MYSQLD_DATADIR ./ --error ER_NOT_FORM_FILE SHOW CREATE TABLE t1; --error ER_BAD_TABLE_ERROR -- cgit v1.2.1 From 55105a88e1f86cf7baff6e284abdeb9c96a8fcfc Mon Sep 17 00:00:00 2001 From: Alexey Kopytov Date: Tue, 24 Aug 2010 19:51:32 +0400 Subject: Bug #54802: 'NOT BETWEEN' evaluation is incorrect Queries involving predicates of the form "const NOT BETWEEN not_indexed_column AND indexed_column" could return wrong data due to incorrect handling by the range optimizer. For "c NOT BETWEEN f1 AND f2" predicates, get_mm_tree() produces a disjunction of the SEL_ARG trees for "f1 > c" and "f2 < c". If one of the trees is empty (i.e. one of the arguments is not sargable) the resulting tree should be empty as well, since the whole expression in this case is not sargable. The above logic is implemented in get_mm_tree() as follows. The initial state of the resulting tree is NULL (aka empty). We then iterate through arguments and compute the corresponding SEL_ARG tree (either "f1 > c" or "f2 < c"). If the resulting tree is NULL, it is simply replaced by the generated tree. Otherwise it is replaced by a disjunction of itself and the generated tree. The obvious flaw in this implementation is that if the first argument is not sargable and thus produces a NULL tree, the resulting tree will simply be replaced by the tree for the second argument. As a result, "c NOT BETWEEN f1 AND f2" will end up as just "f2 < c". Fixed by adding a check so that when the first argument produces an empty tree for the NOT BETWEEN case, the loop is aborted with an empty tree as a result. The whole idea of using a loop for 2 arguments does not make much sense, but it was probably used to avoid code duplication for several BETWEEN variants. --- mysql-test/r/range.result | 13 +++++++++++++ mysql-test/t/range.test | 12 ++++++++++++ 2 files changed, 25 insertions(+) (limited to 'mysql-test') diff --git a/mysql-test/r/range.result b/mysql-test/r/range.result index 64e00521cd2..d989896514c 100644 --- a/mysql-test/r/range.result +++ b/mysql-test/r/range.result @@ -1653,4 +1653,17 @@ a b 0 0 1 1 DROP TABLE t1; +# +# Bug #54802: 'NOT BETWEEN' evaluation is incorrect +# +CREATE TABLE t1 (c_key INT, c_notkey INT, KEY(c_key)); +INSERT INTO t1 VALUES (1, 1), (2, 2), (3, 3); +EXPLAIN SELECT * FROM t1 WHERE 2 NOT BETWEEN c_notkey AND c_key; +id select_type table type possible_keys key key_len ref rows Extra +1 SIMPLE t1 ALL c_key NULL NULL NULL 3 Using where +SELECT * FROM t1 WHERE 2 NOT BETWEEN c_notkey AND c_key; +c_key c_notkey +1 1 +3 3 +DROP TABLE t1; End of 5.1 tests diff --git a/mysql-test/t/range.test b/mysql-test/t/range.test index 5d5ad180f1a..0ad3d3e8504 100644 --- a/mysql-test/t/range.test +++ b/mysql-test/t/range.test @@ -1313,4 +1313,16 @@ SELECT * FROM t1 FORCE INDEX (PRIMARY) DROP TABLE t1; +--echo # +--echo # Bug #54802: 'NOT BETWEEN' evaluation is incorrect +--echo # + +CREATE TABLE t1 (c_key INT, c_notkey INT, KEY(c_key)); +INSERT INTO t1 VALUES (1, 1), (2, 2), (3, 3); + +EXPLAIN SELECT * FROM t1 WHERE 2 NOT BETWEEN c_notkey AND c_key; +SELECT * FROM t1 WHERE 2 NOT BETWEEN c_notkey AND c_key; + +DROP TABLE t1; + --echo End of 5.1 tests -- cgit v1.2.1 From 94100243d1b74bec9101ceb59685447e02014897 Mon Sep 17 00:00:00 2001 From: Evgeny Potemkin Date: Thu, 26 Aug 2010 13:31:04 +0400 Subject: Bug #55656: mysqldump can be slower after bug 39653 fix. After fix for bug 39653 the shortest available secondary index was used for full table scan. Primary clustered key was used only if no secondary index can be used. However, when chosen secondary index includes all fields of the table being scanned it's better to use primary index since the amount of data to scan is the same but the primary index is clustered. Now the find_shortest_key function takes this into account. mysql-test/suite/innodb/r/innodb_mysql.result: Added a test case for the bug#55656. mysql-test/suite/innodb/t/innodb_mysql.test: Added a test case for the bug#55656. sql/sql_select.cc: Bug #55656: mysqldump can be slower after bug #39653 fix. The find_shortest_key function now prefers clustered primary key if found secondary key includes all fields of the table. --- mysql-test/suite/innodb/r/innodb_mysql.result | 58 +++++++++++++++++++++++++++ mysql-test/suite/innodb/t/innodb_mysql.test | 25 ++++++++++++ 2 files changed, 83 insertions(+) (limited to 'mysql-test') diff --git a/mysql-test/suite/innodb/r/innodb_mysql.result b/mysql-test/suite/innodb/r/innodb_mysql.result index 23619b91fbc..ba8ac0ba86c 100644 --- a/mysql-test/suite/innodb/r/innodb_mysql.result +++ b/mysql-test/suite/innodb/r/innodb_mysql.result @@ -2529,4 +2529,62 @@ SELECT * FROM t1 FOR UPDATE; SELECT * FROM t1 GROUP BY (SELECT a FROM t2 LIMIT 1 FOR UPDATE) + t1.a; ERROR 40001: Deadlock found when trying to get lock; try restarting transaction DROP TABLE t1,t2; +# +# Bug#55656: mysqldump can be slower after bug #39653 fix +# +CREATE TABLE t1 (a INT , b INT, c INT, d INT, +KEY (b), PRIMARY KEY (a,b)) ENGINE=INNODB; +INSERT INTO t1 VALUES (1,1,1,1), (2,2,2,2), (3,3,3,3); +EXPLAIN SELECT COUNT(*) FROM t1; +id 1 +select_type SIMPLE +table t1 +type index +possible_keys NULL +key b +key_len 4 +ref NULL +rows 3 +Extra Using index +DROP INDEX b ON t1; +CREATE INDEX b ON t1(a,b); +EXPLAIN SELECT COUNT(*) FROM t1; +id 1 +select_type SIMPLE +table t1 +type index +possible_keys NULL +key b +key_len 8 +ref NULL +rows 3 +Extra Using index +DROP INDEX b ON t1; +CREATE INDEX b ON t1(a,b,c); +EXPLAIN SELECT COUNT(*) FROM t1; +id 1 +select_type SIMPLE +table t1 +type index +possible_keys NULL +key b +key_len 13 +ref NULL +rows 3 +Extra Using index +DROP INDEX b ON t1; +CREATE INDEX b ON t1(a,b,c,d); +EXPLAIN SELECT COUNT(*) FROM t1; +id 1 +select_type SIMPLE +table t1 +type index +possible_keys NULL +key PRIMARY +key_len 8 +ref NULL +rows 3 +Extra Using index +DROP TABLE t1; +# End of 5.1 tests diff --git a/mysql-test/suite/innodb/t/innodb_mysql.test b/mysql-test/suite/innodb/t/innodb_mysql.test index d633cb2222e..4f13e15a627 100644 --- a/mysql-test/suite/innodb/t/innodb_mysql.test +++ b/mysql-test/suite/innodb/t/innodb_mysql.test @@ -781,5 +781,30 @@ disconnect con2; DROP TABLE t1,t2; +--echo # +--echo # Bug#55656: mysqldump can be slower after bug #39653 fix +--echo # + +CREATE TABLE t1 (a INT , b INT, c INT, d INT, + KEY (b), PRIMARY KEY (a,b)) ENGINE=INNODB; +INSERT INTO t1 VALUES (1,1,1,1), (2,2,2,2), (3,3,3,3); +--query_vertical EXPLAIN SELECT COUNT(*) FROM t1 + +DROP INDEX b ON t1; +CREATE INDEX b ON t1(a,b); +--query_vertical EXPLAIN SELECT COUNT(*) FROM t1 + +DROP INDEX b ON t1; +CREATE INDEX b ON t1(a,b,c); +--query_vertical EXPLAIN SELECT COUNT(*) FROM t1 + +DROP INDEX b ON t1; +CREATE INDEX b ON t1(a,b,c,d); +--query_vertical EXPLAIN SELECT COUNT(*) FROM t1 + +DROP TABLE t1; + +--echo # + --echo End of 5.1 tests -- cgit v1.2.1 From d61b21c3d74f82dc16550af109cb57f6e1727710 Mon Sep 17 00:00:00 2001 From: Sergey Vojtovich Date: Thu, 26 Aug 2010 15:23:44 +0400 Subject: Fixed race condition in a test case for BUG#55580. --- mysql-test/suite/innodb/t/innodb_mysql.test | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'mysql-test') diff --git a/mysql-test/suite/innodb/t/innodb_mysql.test b/mysql-test/suite/innodb/t/innodb_mysql.test index 4f13e15a627..ae03bebfbe3 100644 --- a/mysql-test/suite/innodb/t/innodb_mysql.test +++ b/mysql-test/suite/innodb/t/innodb_mysql.test @@ -768,9 +768,14 @@ START TRANSACTION; SELECT * FROM t1 LOCK IN SHARE MODE; connection con1; +let $conn_id= `SELECT CONNECTION_ID()`; --send SELECT * FROM t1 FOR UPDATE connection con2; +let $wait_timeout= 2; +let $wait_condition= SELECT 1 FROM INFORMATION_SCHEMA.PROCESSLIST +WHERE ID=$conn_id AND STATE='Sending data'; +--source include/wait_condition.inc --echo # should not crash --error ER_LOCK_DEADLOCK SELECT * FROM t1 GROUP BY (SELECT a FROM t2 LIMIT 1 FOR UPDATE) + t1.a; -- cgit v1.2.1 From 36e234a80a11edac3615079d5e384a6cbcb23739 Mon Sep 17 00:00:00 2001 From: Alexey Kopytov Date: Fri, 27 Aug 2010 13:44:35 +0400 Subject: Bug #54465: assert: field_types == 0 || field_types[field_pos] == MYSQL_TYPE_LONGLONG A MIN/MAX() function with a subquery as its argument could lead to a debug assertion on debug builds or wrong data on release ones. The problem was a combination of the following factors: - Item_sum_hybrid::fix_fields() might use the argument (args[0]) to calculate 'hybrid_field_type' which was later used to decide how the data should be sent to the client. - Item_sum::make_field() might use the argument again to calculate the field's type when sending result set metadata to the client. - The argument could be changed in between these two calls via Item::set_arg() leading to inconsistent metadata being reported. Here is what was happening for the bug's test case: 1. Item_sum_hybrid::fix_fields() calculates hybrid_field_type as MYSQL_TYPE_LONGLONG based on args[0] which is an Item::SUBSELECT_ITEM at that time. 2. A temporary table is created to execute the query. create_tmp_field_from_item() creates a Field_long object according to the subselect's max_length. 3. The subselect item in Item_sum_hybrid is replaced by the Item_field object referencing the newly created Field_long. 4. Item_sum::make_field() rightfully returns the MYSQL_TYPE_LONG type when calculating the result set metadata. 5. When sending the actual data, Item::send() relies on the virtual field_type() function which in our case returns previously calculated hybrid_field_type == MYSQL_TYPE_LONGLONG. It looks like the only solution is to never refer to the argument's metadata after the result metadata has been calculated in fix_fields(), since the argument itself may be different by then. In this sense, Item_sum::make_field() should never be used, because it may rely on the argument's metadata and is only called after fix_fields(). The "default" implementation in Item::make_field() should be used instead as it relies only on field_type(), but not on the argument's type. Fixed by removing Item_sum::make_field() so that the superclass implementation Item::make_field() is always used. mysql-test/r/func_group.result: Added a test case for bug #54465. mysql-test/t/func_group.test: Added a test case for bug #54465. sql/item_sum.cc: Removed Item_sum::make_field() so that the superclass implementation Item::make_field() is always used. sql/item_sum.h: Removed Item_sum::make_field() so that the superclass implementation Item::make_field() is always used. --- mysql-test/r/func_group.result | 11 +++++++++++ mysql-test/t/func_group.test | 14 ++++++++++++++ 2 files changed, 25 insertions(+) (limited to 'mysql-test') diff --git a/mysql-test/r/func_group.result b/mysql-test/r/func_group.result index b36f561578b..606f879b47f 100644 --- a/mysql-test/r/func_group.result +++ b/mysql-test/r/func_group.result @@ -1713,4 +1713,15 @@ f1 f2 f3 f4 f1 = f2 NULL NULL NULL NULL NULL drop table t1; # +# Bug #54465: assert: field_types == 0 || field_types[field_pos] == +# MYSQL_TYPE_LONGLONG +# +CREATE TABLE t1 (a INT); +INSERT INTO t1 VALUES (1), (2); +SELECT MAX((SELECT 1 FROM t1 ORDER BY @var LIMIT 1)) m FROM t1 t2, t1 +ORDER BY t1.a; +m +1 +DROP TABLE t1; +# End of 5.1 tests diff --git a/mysql-test/t/func_group.test b/mysql-test/t/func_group.test index 6dbc8a05789..72a78f612a2 100644 --- a/mysql-test/t/func_group.test +++ b/mysql-test/t/func_group.test @@ -1082,6 +1082,20 @@ select a.f1 as a, b.f4 as b, a.f1 > b.f4 as gt, from t1 a, t1 b; select *, f1 = f2 from t1; drop table t1; + +--echo # +--echo # Bug #54465: assert: field_types == 0 || field_types[field_pos] == +--echo # MYSQL_TYPE_LONGLONG +--echo # + +CREATE TABLE t1 (a INT); +INSERT INTO t1 VALUES (1), (2); + +SELECT MAX((SELECT 1 FROM t1 ORDER BY @var LIMIT 1)) m FROM t1 t2, t1 + ORDER BY t1.a; + +DROP TABLE t1; + --echo # --echo End of 5.1 tests -- cgit v1.2.1 From 4f5288f18199509adac2d76a15858da63fa3c2e2 Mon Sep 17 00:00:00 2001 From: Ramil Kalimullin Date: Mon, 30 Aug 2010 11:51:46 +0400 Subject: Fix for bug #51875: crash when loading data into geometry function polyfromwkb Check for number of line strings in the incoming polygon data (wkb) and for number of points in the incoming linestring wkb. mysql-test/r/gis.result: Fix for bug #51875: crash when loading data into geometry function polyfromwkb - test result. mysql-test/t/gis.test: Fix for bug #51875: crash when loading data into geometry function polyfromwkb - test case. sql/spatial.cc: Fix for bug #51875: crash when loading data into geometry function polyfromwkb - creating a polygon from wkb check for number of line strings, - creating a linestring from wkb check for number of line points. --- mysql-test/r/gis.result | 7 +++++++ mysql-test/t/gis.test | 10 ++++++++++ 2 files changed, 17 insertions(+) (limited to 'mysql-test') diff --git a/mysql-test/r/gis.result b/mysql-test/r/gis.result index 3e28227d542..d39afa6f315 100644 --- a/mysql-test/r/gis.result +++ b/mysql-test/r/gis.result @@ -1057,4 +1057,11 @@ NULL SELECT Polygon(12345123,''); Polygon(12345123,'') NULL +# +# BUG#51875: crash when loading data into geometry function polyfromwkb +# +SET @a=0x00000000030000000100000000000000000000000000144000000000000014400000000000001840000000000000184000000000000014400000000000001440; +SET @a=POLYFROMWKB(@a); +SET @a=0x00000000030000000000000000000000000000000000144000000000000014400000000000001840000000000000184000000000000014400000000000001440; +SET @a=POLYFROMWKB(@a); End of 5.1 tests diff --git a/mysql-test/t/gis.test b/mysql-test/t/gis.test index bc0695aaa93..236b31efb79 100644 --- a/mysql-test/t/gis.test +++ b/mysql-test/t/gis.test @@ -722,4 +722,14 @@ SELECT Polygon(123451,''); SELECT Polygon(1234512,''); SELECT Polygon(12345123,''); + +--echo # +--echo # BUG#51875: crash when loading data into geometry function polyfromwkb +--echo # +SET @a=0x00000000030000000100000000000000000000000000144000000000000014400000000000001840000000000000184000000000000014400000000000001440; +SET @a=POLYFROMWKB(@a); +SET @a=0x00000000030000000000000000000000000000000000144000000000000014400000000000001840000000000000184000000000000014400000000000001440; +SET @a=POLYFROMWKB(@a); + + --echo End of 5.1 tests -- cgit v1.2.1 From 07024ab7ad258fcbe1defe5418fff4f9a81a81bc Mon Sep 17 00:00:00 2001 From: Gleb Shchepa Date: Tue, 31 Aug 2010 02:16:38 +0400 Subject: Bug #53034: Multiple-table DELETE statements not accepting "Access compatibility" syntax The "wild" "DELETE FROM table_name.* ... USING ..." syntax for multi-table DELETE statements is documented but it was lost in the fix for the bug 30234. The table_ident_opt_wild parser rule has been added to restore the lost syntax. mysql-test/r/delete.result: Test case for bug #53034. mysql-test/t/delete.test: Test case for bug #53034. sql/sql_yacc.yy: Bug #53034: Multiple-table DELETE statements not accepting "Access compatibility" syntax The table_ident_opt_wild parser rule has been added to restore the lost syntax. Note: simple extending of table_ident with opt_wild in the table_alias_ref rule is not acceptable, because a) it adds one conflict more and b) this conflict resolves in the inappropriate way. --- mysql-test/r/delete.result | 9 +++++++++ mysql-test/t/delete.test | 13 +++++++++++++ 2 files changed, 22 insertions(+) (limited to 'mysql-test') diff --git a/mysql-test/r/delete.result b/mysql-test/r/delete.result index 36025cbfb35..7d6fc30be67 100644 --- a/mysql-test/r/delete.result +++ b/mysql-test/r/delete.result @@ -358,4 +358,13 @@ INDEX(a), INDEX(b), INDEX(c)); INSERT INTO t1 VALUES (1,2,3), (4,5,6), (7,8,9); DELETE FROM t1 WHERE a = 10 OR b = 20 ORDER BY c LIMIT 1; DROP TABLE t1; +# +# Bug #53034: Multiple-table DELETE statements not accepting +# "Access compatibility" syntax +# +CREATE TABLE t1 (id INT); +CREATE TABLE t2 LIKE t1; +CREATE TABLE t3 LIKE t1; +DELETE FROM t1.*, test.t2.*, a.* USING t1, t2, t3 AS a; +DROP TABLE t1, t2, t3; End of 5.1 tests diff --git a/mysql-test/t/delete.test b/mysql-test/t/delete.test index 5a0e86568f3..ea5c87babbb 100644 --- a/mysql-test/t/delete.test +++ b/mysql-test/t/delete.test @@ -387,4 +387,17 @@ DELETE FROM t1 WHERE a = 10 OR b = 20 ORDER BY c LIMIT 1; DROP TABLE t1; +--echo # +--echo # Bug #53034: Multiple-table DELETE statements not accepting +--echo # "Access compatibility" syntax +--echo # + +CREATE TABLE t1 (id INT); +CREATE TABLE t2 LIKE t1; +CREATE TABLE t3 LIKE t1; + +DELETE FROM t1.*, test.t2.*, a.* USING t1, t2, t3 AS a; + +DROP TABLE t1, t2, t3; + --echo End of 5.1 tests -- cgit v1.2.1 From d8b3cde7c34ecb2e0d767de2dc29b4037b973e0e Mon Sep 17 00:00:00 2001 From: Alexey Kopytov Date: Thu, 26 Aug 2010 14:13:02 +0400 Subject: Bug #53544: Server hangs during JOIN query in stored procedure called twice in a row Queries with nested joins could cause an infinite loop in the server when used from SP/PS. When flattening nested joins, simplify_joins() tracks if the name resolution list needs to be updated by setting fix_name_res to TRUE if the current loop iteration has done any transformations to the join table list. The problem was that the flag was not reset before the next loop iteration leading to unnecessary "fixing" of the name resolution list which in turn could lead to a loop (i.e. circularly-linked part) in that list. This was causing problems on subsequent execution when used together with stored procedures or prepared statements. Fixed by making sure fix_name_res is reset on every loop iteration. mysql-test/r/join.result: Added a test case for bug #53544. mysql-test/t/join.test: Added a test case for bug #53544. sql/sql_select.cc: Make sure fix_name_res is reset on every loop iteration. --- mysql-test/r/join.result | 20 ++++++++++++++++++++ mysql-test/t/join.test | 20 ++++++++++++++++++++ 2 files changed, 40 insertions(+) (limited to 'mysql-test') diff --git a/mysql-test/r/join.result b/mysql-test/r/join.result index c3c292b2106..9a8b441b363 100644 --- a/mysql-test/r/join.result +++ b/mysql-test/r/join.result @@ -1235,4 +1235,24 @@ ORDER BY t1.a, t1.a LIMIT 1) AS d) 1 1 DROP TABLE t1; +# +# Bug #53544: Server hangs during JOIN query in stored procedure called +# twice in a row +# +CREATE TABLE t1(c INT); +INSERT INTO t1 VALUES (1), (2); +PREPARE stmt FROM "SELECT t2.c AS f1 FROM t1 LEFT JOIN + t1 t2 ON t1.c=t2.c RIGHT JOIN + t1 t3 ON t1.c=t3.c + GROUP BY f1;"; +EXECUTE stmt; +f1 +1 +2 +EXECUTE stmt; +f1 +1 +2 +DEALLOCATE PREPARE stmt; +DROP TABLE t1; End of 5.1 tests diff --git a/mysql-test/t/join.test b/mysql-test/t/join.test index 6969be6fdc4..73a1ae5eb82 100644 --- a/mysql-test/t/join.test +++ b/mysql-test/t/join.test @@ -897,4 +897,24 @@ GREATEST(t1.a, DROP TABLE t1; +--echo # +--echo # Bug #53544: Server hangs during JOIN query in stored procedure called +--echo # twice in a row +--echo # + +CREATE TABLE t1(c INT); + +INSERT INTO t1 VALUES (1), (2); + +PREPARE stmt FROM "SELECT t2.c AS f1 FROM t1 LEFT JOIN + t1 t2 ON t1.c=t2.c RIGHT JOIN + t1 t3 ON t1.c=t3.c + GROUP BY f1;"; + +EXECUTE stmt; +EXECUTE stmt; + +DEALLOCATE PREPARE stmt; +DROP TABLE t1; + --echo End of 5.1 tests -- cgit v1.2.1