From 313c5a01eea6fe4ab528066a7b14fe6b63e2c633 Mon Sep 17 00:00:00 2001 From: Georgi Kodinov Date: Tue, 27 Oct 2009 14:43:12 +0200 Subject: Bug #47930: MATCH IN BOOLEAN MODE returns too many results inside subquery Re-setting a fulltext index was a no-operation if not all the matches of a search were consumed by reading them. This was preventing a joined table using a fulltext index in a subquery that requires only 1 row of output (e.g. EXISTS) from working correctly because the second execution of the sub-query has the fulltext index cursor in a wrong state and was not finding results. Fixed by making the re-init code _ftb_init_index_search() to re-set open cursors in addition to depleted ones. --- mysql-test/r/fulltext.result | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/fulltext.result b/mysql-test/r/fulltext.result index a5216189d9a..6022231907b 100644 --- a/mysql-test/r/fulltext.result +++ b/mysql-test/r/fulltext.result @@ -551,3 +551,42 @@ EXECUTE s; MATCH (col) AGAINST('findme') DEALLOCATE PREPARE s; DROP TABLE t1; +# +# Bug #47930: MATCH IN BOOLEAN MODE returns too many results +# inside subquery +# +CREATE TABLE t1 (a int); +INSERT INTO t1 VALUES (1), (2); +CREATE TABLE t2 (a int, b2 char(10), FULLTEXT KEY b2 (b2)); +INSERT INTO t2 VALUES (1,'Scargill'); +CREATE TABLE t3 (a int, b int); +INSERT INTO t3 VALUES (1,1), (2,1); +# t2 should use full text index +EXPLAIN +SELECT count(*) FROM t1 WHERE +not exists( +SELECT 1 FROM t2, t3 +WHERE t3.a=t1.a AND MATCH(b2) AGAINST('scargill' IN BOOLEAN MODE) +); +id select_type table type possible_keys key key_len ref rows Extra +1 PRIMARY t1 ALL NULL NULL NULL NULL 2 Using where +2 DEPENDENT SUBQUERY t2 fulltext b2 b2 0 1 Using where +2 DEPENDENT SUBQUERY t3 ALL NULL NULL NULL NULL 2 Using where +# should return 0 +SELECT count(*) FROM t1 WHERE +not exists( +SELECT 1 FROM t2, t3 +WHERE t3.a=t1.a AND MATCH(b2) AGAINST('scargill' IN BOOLEAN MODE) +); +count(*) +0 +# should return 0 +SELECT count(*) FROM t1 WHERE +not exists( +SELECT 1 FROM t2 IGNORE INDEX (b2), t3 +WHERE t3.a=t1.a AND MATCH(b2) AGAINST('scargill' IN BOOLEAN MODE) +); +count(*) +0 +DROP TABLE t1,t2,t3; +End of 5.1 tests -- cgit v1.2.1 From be04d1a47953188ced936a81824fdf871b8e9656 Mon Sep 17 00:00:00 2001 From: "Tatiana A. Nurnberg" Date: Thu, 29 Oct 2009 22:06:10 -0700 Subject: Bug#48319: Server crashes on "GRANT/REVOKE ... TO CURRENT_USER" CURRENT_USER() in GRANT ... TO CURRENT_USER() only gave us a definer, not a full user (i.e., password-element was not initiliazed). Hence dereferencing the password led to a crash. Properly initializes definers now, just so there are no misunderstandings. Also does some magic so IDENTIFIED BY ... works with CURRENT_USER(). mysql-test/r/grant2.result: Show GRANT ... TO CURRENT_USER() no longer crashes. Show it to work with IDENTIFIED BY to boot. mysql-test/t/grant2.test: Show GRANT ... TO CURRENT_USER() no longer crashes. Show it to work with IDENTIFIED BY to boot. sql/sql_acl.cc: Make IDENTIFIED BY ... work with CURRENT_USER() sql/sql_parse.cc: Zero password-part of definer just in case somebody mistakes this for a complete LEX_USER! --- mysql-test/r/grant2.result | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/grant2.result b/mysql-test/r/grant2.result index 7c2023127f0..12269f0cb1c 100644 --- a/mysql-test/r/grant2.result +++ b/mysql-test/r/grant2.result @@ -443,3 +443,30 @@ DROP TABLE db1.t1, db1.t2; DROP USER mysqltest1@localhost; DROP DATABASE db1; End of 5.0 tests +USE mysql; +SELECT LEFT(CURRENT_USER(),INSTR(CURRENT_USER(),'@')-1) INTO @u; +SELECT MID(CURRENT_USER(),INSTR(CURRENT_USER(),'@')+1) INTO @h; +SELECT password FROM user WHERE user=@u AND host=@h INTO @pwd; +SELECT user,host,password,insert_priv FROM user WHERE user=@u AND host=@h; +user host password insert_priv +root localhost Y +UPDATE user SET insert_priv='N' WHERE user=@u AND host=@h; +SELECT user,host,password,insert_priv FROM user WHERE user=@u AND host=@h; +user host password insert_priv +root localhost N +GRANT INSERT ON *.* TO CURRENT_USER(); +SELECT user,host,password,insert_priv FROM user WHERE user=@u AND host=@h; +user host password insert_priv +root localhost Y +UPDATE user SET insert_priv='N' WHERE user=@u AND host=@h; +GRANT INSERT ON *.* TO CURRENT_USER() IDENTIFIED BY 'keksdose'; +SELECT user,host,password,insert_priv FROM user WHERE user=@u AND host=@h; +user host password insert_priv +root localhost *0BB7188CF0DE9B403BA66E9DD810D82652D002EB Y +UPDATE user SET password=@pwd WHERE user=@u AND host=@h; +SELECT user,host,password,insert_priv FROM user WHERE user=@u AND host=@h; +user host password insert_priv +root localhost Y +FLUSH PRIVILEGES; +USE test; +End of 5.1 tests -- cgit v1.2.1 From b35feb1ed0aa934ea244163ecea54b5e45157138 Mon Sep 17 00:00:00 2001 From: Mattias Jonsson Date: Tue, 3 Nov 2009 09:22:01 +0100 Subject: Bug#46923: select count(*) from partitioned table fails with ONLY_FULL_GROUP_BY Problem was that during checking and preparation of the partitioining function as a side effect in fix_fields the full_group_by_flag was changed. Solution was to set it back to its original value after calling fix_fields. Updated patch, to also exclude allow_sum_func from being affected of fix_fields, as requested by reviewer. mysql-test/r/partition.result: Bug#46923: select count(*) from partitioned table fails with ONLY_FULL_GROUP_BY Updated result file mysql-test/t/partition.test: Bug#46923: select count(*) from partitioned table fails with ONLY_FULL_GROUP_BY Extended test case to cover this bug sql/sql_partition.cc: Bug#46923: select count(*) from partitioned table fails with ONLY_FULL_GROUP_BY Resetting full_group_by_flag and allow_sum_func back to their original values, not conflicting with the sql_mode 'ONLY_FULL_GROUP_BY' --- mysql-test/r/partition.result | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/partition.result b/mysql-test/r/partition.result index 2d54a66fe11..abdeb3a77e1 100644 --- a/mysql-test/r/partition.result +++ b/mysql-test/r/partition.result @@ -2030,10 +2030,15 @@ DROP TABLE t1; # # Bug #45807: crash accessing partitioned table and sql_mode # contains ONLY_FULL_GROUP_BY +# Bug#46923: select count(*) from partitioned table fails with +# ONLY_FULL_GROUP_BY # SET SESSION SQL_MODE='ONLY_FULL_GROUP_BY'; CREATE TABLE t1(id INT,KEY(id)) ENGINE=MYISAM PARTITION BY HASH(id) PARTITIONS 2; +SELECT COUNT(*) FROM t1; +COUNT(*) +0 DROP TABLE t1; SET SESSION SQL_MODE=DEFAULT; # -- cgit v1.2.1 From 43d7fb43cd965ae8e53d8253388b6ac58a7ebddc Mon Sep 17 00:00:00 2001 From: Georgi Kodinov Date: Wed, 4 Nov 2009 13:54:28 +0200 Subject: Bug #46175: NULL read_view and consistent read assertion The SE API requires mysql to notify the storage engine that it's going to read certain tables at the beginning of the statement (by calling start_stmt(), store_lock() or external_lock()). These are typically called by the lock_tables(). However SHOW CREATE TABLE is not pre-locking the tables because it's not expected to access the data at all. But for some view definitions (that include comparing a date/datetime/timestamp column to a string returning scalar subquery) the JOIN::prepare may still access data when materializing the scalar non-correlated subquery in Arg_comparator::can_compare_as_dates(). Fixed by not materializing the subquery when the function is called in a SHOW/EXPLAIN/CREATE VIEW --- mysql-test/r/innodb_mysql.result | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/innodb_mysql.result b/mysql-test/r/innodb_mysql.result index c882d2af1ed..402ab3c1b16 100644 --- a/mysql-test/r/innodb_mysql.result +++ b/mysql-test/r/innodb_mysql.result @@ -2251,4 +2251,26 @@ c >= '2009-10-09 00:00:00.001' AND c <= '2009-10-09 00:00:00.00'; id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables DROP TABLE t1; +# +# Bug #46175: NULL read_view and consistent read assertion +# +CREATE TABLE t1(a CHAR(13),KEY(a)) ENGINE=innodb; +CREATE TABLE t2(b DATETIME,KEY(b)) ENGINE=innodb; +INSERT INTO t1 VALUES (),(); +INSERT INTO t2 VALUES (),(); +CREATE OR REPLACE VIEW v1 AS SELECT 1 FROM t2 +WHERE b =(SELECT a FROM t1 LIMIT 1); +CREATE PROCEDURE p1(num INT) +BEGIN +DECLARE i INT DEFAULT 0; +REPEAT +SHOW CREATE VIEW v1; +SET i:=i+1; +UNTIL i>num END REPEAT; +END| +# Should not crash +# Should not crash +DROP PROCEDURE p1; +DROP VIEW v1; +DROP TABLE t1,t2; End of 5.1 tests -- cgit v1.2.1 From 39f9a3ffd0de8828be2a43b9674a19fa58c52f98 Mon Sep 17 00:00:00 2001 From: Alexey Kopytov Date: Fri, 6 Nov 2009 09:44:01 +0300 Subject: Bug #48475: DISTINCT is ignored with GROUP BY WITH ROLLUP and only const tables The problem was caused by two shortcuts in the optimizer that are inapplicable in the ROLLUP case. Normally in a case when only const tables are involved in a query, DISTINCT clause can be safely optimized away since there may be only one row produced by the join. Similarly, we don't need to create a temporary table to resolve DISTINCT/GROUP BY/ORDER BY. Both of these are inapplicable when the WITH ROLLUP modifier is present. Fixed by disabling the said optimizations for the WITH ROLLUP case. mysql-test/r/olap.result: Added a test case for bug #48475. mysql-test/t/olap.test: Added a test case for bug #48475. sql/sql_select.cc: Disabled const-only table optimizations for the WITH ROLLUP case. --- mysql-test/r/olap.result | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/olap.result b/mysql-test/r/olap.result index 56e06f03378..eabe3a50309 100644 --- a/mysql-test/r/olap.result +++ b/mysql-test/r/olap.result @@ -753,4 +753,16 @@ b 100 NULL DROP TABLE t1, t2; +# +# Bug #48475: DISTINCT is ignored with GROUP BY WITH ROLLUP +# and only const tables +CREATE TABLE t1 (a INT); +CREATE TABLE t2 (b INT); +INSERT INTO t1 VALUES (1); +INSERT INTO t2 VALUES (1); +SELECT DISTINCT b FROM t1, t2 GROUP BY a, b WITH ROLLUP; +b +1 +NULL +DROP TABLE t1, t2; End of 5.0 tests -- cgit v1.2.1 From 785b5c4e7a06445d2b23b57c3dce120828844c69 Mon Sep 17 00:00:00 2001 From: Mattias Jonsson Date: Mon, 9 Nov 2009 11:26:01 +0100 Subject: Bug#48276: can't add column if subpartition exists Bug when setting up default partitioning, used an uninitialized variabe. mysql-test/r/partition.result: Bug#48276: can't add column if subpartition exists Added result mysql-test/t/partition.test: Bug#48276: can't add column if subpartition exists Added test sql/sql_partition.cc: Bug#48276: can't add column if subpartition exists even if is_create_table_ind was set, one tried to set no_subparts with the unitialized no_parts local variable. Fixed by rearrange the code to be to only execute the statements when is_create_table_ind was not set. --- mysql-test/r/partition.result | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/partition.result b/mysql-test/r/partition.result index 6611d39628f..9ee62c978d0 100644 --- a/mysql-test/r/partition.result +++ b/mysql-test/r/partition.result @@ -1,4 +1,10 @@ drop table if exists t1, t2; +CREATE TABLE t1 (a INT, b INT) +PARTITION BY LIST (a) +SUBPARTITION BY HASH (b) +(PARTITION p1 VALUES IN (1)); +ALTER TABLE t1 ADD COLUMN c INT; +DROP TABLE t1; CREATE TABLE t1 ( a int NOT NULL, b int NOT NULL); -- cgit v1.2.1 From ddd90017e75cf1241da12cdc3fd55b44da0c4a9d Mon Sep 17 00:00:00 2001 From: Georgi Kodinov Date: Tue, 10 Nov 2009 10:21:41 +0200 Subject: Bug #42760: Select doesn't return desired results when we have null values We should re-set the access method functions when changing the access method when switching to another index to avoid sorting. Fixed by doing a little re-engineering : encapsulating all the function assignment into a special function and calling it when flipping the indexes. --- mysql-test/r/order_by.result | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/order_by.result b/mysql-test/r/order_by.result index f64bbc79cbd..f0e5b5fde3d 100644 --- a/mysql-test/r/order_by.result +++ b/mysql-test/r/order_by.result @@ -1092,3 +1092,24 @@ FROM t3; 2 NULL DROP TABLE t1, t2, t3; +# +# Bug #42760: Select doesn't return desired results when we have null +# values +# +CREATE TABLE t1 ( +a INT, +c INT, +UNIQUE KEY a_c (a,c), +KEY (a)); +INSERT INTO t1 VALUES (1, 10), (2, NULL); +# Must use ref-or-null on the a_c index +EXPLAIN +SELECT 1 AS col FROM t1 WHERE a=2 AND (c=10 OR c IS NULL) ORDER BY c; +id select_type table type possible_keys key key_len ref rows Extra +1 SIMPLE t1 ref_or_null a_c,a a_c 10 const,const 1 Using where +# Must return 1 row +SELECT 1 AS col FROM t1 WHERE a=2 AND (c=10 OR c IS NULL) ORDER BY c; +col +1 +DROP TABLE t1; +End of 5.0 tests -- cgit v1.2.1 From 4519d5e4f1ce1c9081f711d88d7508f58453d219 Mon Sep 17 00:00:00 2001 From: Georgi Kodinov Date: Mon, 9 Nov 2009 16:09:46 +0200 Subject: Bug #48458: simple query tries to allocate enormous amount of memory The server was doing a bad class typecast causing setting of wrong value for the maximum number of items in an internal structure used in equality propagation. Fixed by not doing the wrong typecast and asserting the type of the Item where it should be done. --- mysql-test/r/select.result | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/select.result b/mysql-test/r/select.result index 5d07c97149f..ff59eadab0c 100644 --- a/mysql-test/r/select.result +++ b/mysql-test/r/select.result @@ -4442,4 +4442,18 @@ ROW(a,a) <=> ROW((SELECT 1 FROM t1 WHERE 1=2),(SELECT 1 FROM t1)) INTO @var0; ERROR 21000: Subquery returns more than 1 row DROP TABLE t1; +# +# Bug #48458: simple query tries to allocate enormous amount of +# memory +# +CREATE TABLE t1(a INT NOT NULL, b YEAR); +INSERT INTO t1 VALUES (); +Warnings: +Warning 1364 Field 'a' doesn't have a default value +CREATE TABLE t2(c INT); +# Should not err out because of out-of-memory +SELECT 1 FROM t2 JOIN t1 ON 1=1 +WHERE a != '1' AND NOT a >= b OR NOT ROW(b,a )<> ROW(a,a); +1 +DROP TABLE t1,t2; End of 5.0 tests -- cgit v1.2.1 From c87375150b922526f9699aee86614481ac711ad0 Mon Sep 17 00:00:00 2001 From: Anurag Shekhar Date: Wed, 11 Nov 2009 13:33:29 +0530 Subject: Bug #47012 archive tables are not upgradeable, and server crashes on any access Archive engine for 5.1 (and latter) version uses a modified version of zlib (azlib). These two version are incompatible so a proper upgrade is needed before tables created in 5.0 can be used reliable. This upgrade can be performed using repair. But due to lack of test its risky to allow upgrade for now. This patch addresses only the crashing issue. Any attempt to repair will be blocked. Eventually repair can be allowed to run through (which will also cause an upgrade from older version to newer) but only after a thorough testing. mysql-test/r/archive.result: Updated result file for test case for bug#47012 mysql-test/std_data/bug47012.ARM: part of archive table (t1) created in mysql 5.0 mysql-test/std_data/bug47012.ARZ: part of archive table (t1) created in mysql 5.0 mysql-test/std_data/bug47012.frm: part of archive table (t1) created in mysql 5.0 mysql-test/t/archive.test: Added test case for bug#47012. storage/archive/azio.c: Fixed a minor issues (minor version overwriting version in stream structure) Removed assertion when an older version is found. Instead setting the correct version (2) in s->version If an unknown version is found marked it as corrupt. storage/archive/ha_archive.cc: Detecting the archive version in getShare and marking it as need to upgrade. Blocking open if the archive needs an upgrade. This can be allowed in case of open for repair to upgrade the archive but needs to tested. --- mysql-test/r/archive.result | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/archive.result b/mysql-test/r/archive.result index e865d775c6a..c620eb97cab 100644 --- a/mysql-test/r/archive.result +++ b/mysql-test/r/archive.result @@ -12717,3 +12717,14 @@ COUNT(t1.a) 729 DROP TABLE t1; SET @@join_buffer_size= @save_join_buffer_size; +SHOW CREATE TABLE t1; +ERROR HY000: Table upgrade required. Please do "REPAIR TABLE `t1`" or dump/reload to fix it! +SELECT * FROM t1; +ERROR HY000: Table upgrade required. Please do "REPAIR TABLE `t1`" or dump/reload to fix it! +INSERT INTO t1 (col1, col2) VALUES (1, "value"); +ERROR HY000: Table upgrade required. Please do "REPAIR TABLE `t1`" or dump/reload to fix it! +REPAIR TABLE t1; +Table Op Msg_type Msg_text +test.t1 repair Error Table upgrade required. Please do "REPAIR TABLE `t1`" or dump/reload to fix it! +test.t1 repair error Corrupt +DROP TABLE t1; -- cgit v1.2.1 From 552965eff927dff2f0248169e5c0510ef3783ccf Mon Sep 17 00:00:00 2001 From: Magne Mahre Date: Thu, 12 Nov 2009 12:43:33 +0100 Subject: Bug #37183 insert ignore into .. select ... hangs after deadlock was encountered The bug is caused by an inconsistent handling of the IGNORE clause. A read from a const table caused a lock timeout (ER_LOCK_TIMEOUT) in innodb. Since the IGNORE clause was given, the timeout was converted into a warning instead of an error, thus not populating the diagnostics area. When innodb subsequently marked the transaction for rollback, mysql asserted since the diag.area was empty. This patch consists of only a test case, as the bug itself was fixed by the patch for Bug #46539 --- mysql-test/r/innodb_lock_wait_timeout_1.result | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/innodb_lock_wait_timeout_1.result b/mysql-test/r/innodb_lock_wait_timeout_1.result index a635b0d527a..bd8760b8f79 100644 --- a/mysql-test/r/innodb_lock_wait_timeout_1.result +++ b/mysql-test/r/innodb_lock_wait_timeout_1.result @@ -48,6 +48,24 @@ commit; set autocommit=default; drop table t1; # +# Bug #37183 insert ignore into .. select ... hangs +# after deadlock was encountered +# +create table t1(id int primary key,v int)engine=innodb; +insert into t1 values (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7); +create table t2 like t1; +begin; +update t1 set v=id*2 where id=1; +begin; +update t1 set v=id*2 where id=2; +update t1 set v=id*2 where id=2; +ERROR HY000: Lock wait timeout exceeded; try restarting transaction +insert ignore into t2 select * from t1 where id=1; +ERROR HY000: Lock wait timeout exceeded; try restarting transaction +rollback; +rollback; +drop table t1, t2; +# # Bug#41756 Strange error messages about locks from InnoDB # drop table if exists t1; -- cgit v1.2.1 From 356b3df7430a46b3472682a827e357b3f7482257 Mon Sep 17 00:00:00 2001 From: Davi Arnaut Date: Thu, 12 Nov 2009 23:03:26 -0200 Subject: Bug#47627 SET @@{global.session}.local_variable in stored routine causes crash This patch borrows ideas, text and code from Kristofer Pettersson's patch. An assignment of a system variable sharing the same base name as a declared stored procedure variable in the same context could lead to a crash. The reason was that during the parsing of the syntactic rule 'option_value' an uninitialized set_var object was pushed to the parameter stack of the SET statement. The parent rule 'option_type_value' interpreted the existence of variables on the parameter stack as an assignment and wrapped it in a sp_instr_set object. As the procedure later was executed an attempt was made to run the method 'check()' on an uninitialized member object (NULL value) belonging to the previously created but uninitialized object. This patch refactors the 'internal_variable_name' rule and copies the semantic analysis part to the depending parent rule: 'option_value'. This makes it possible to account for any prefixes affecting the interpretation of the internal_variable_name. mysql-test/r/sp.result: Add test case result. mysql-test/t/sp.test: Add test case for bug. sql/sql_yacc.yy: - Reduce churn in rule sys_option_value by moving to specialized functions. - Comment the the lookup in the rule internel_variable_name is a best effort operation. - Lookup for a system variable in the option_value if one was not found (the variable could have been shadowed) --- mysql-test/r/sp.result | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/sp.result b/mysql-test/r/sp.result index 67514c314f4..83ad7545685 100644 --- a/mysql-test/r/sp.result +++ b/mysql-test/r/sp.result @@ -6979,6 +6979,64 @@ CALL p1; ERROR 42S22: Unknown column 'A.b' in 'IN/ALL/ANY subquery' DROP PROCEDURE p1; DROP TABLE t1, t2; +# +# Bug#47627: SET @@{global.session}.local_variable in stored routine causes crash +# Bug#48626: Crash or lost connection using SET for declared variables with @@ +# +DROP PROCEDURE IF EXISTS p1; +DROP PROCEDURE IF EXISTS p2; +DROP PROCEDURE IF EXISTS p3; +CREATE PROCEDURE p1() +BEGIN +DECLARE v INT DEFAULT 0; +SET @@SESSION.v= 10; +END// +ERROR HY000: Unknown system variable 'v' +CREATE PROCEDURE p2() +BEGIN +DECLARE v INT DEFAULT 0; +SET v= 10; +END// +call p2()// +CREATE PROCEDURE p3() +BEGIN +DECLARE v INT DEFAULT 0; +SELECT @@SESSION.v; +END// +ERROR HY000: Unknown system variable 'v' +CREATE PROCEDURE p4() +BEGIN +DECLARE v INT DEFAULT 0; +SET @@GLOBAL.v= 10; +END// +ERROR HY000: Unknown system variable 'v' +CREATE PROCEDURE p5() +BEGIN +DECLARE init_connect INT DEFAULT 0; +SET init_connect= 10; +SET @@GLOBAL.init_connect= 'SELECT 1'; +SET @@SESSION.IDENTITY= 1; +SELECT @@SESSION.IDENTITY; +SELECT @@GLOBAL.init_connect; +SELECT init_connect; +END// +CREATE PROCEDURE p6() +BEGIN +DECLARE v INT DEFAULT 0; +SET @@v= 0; +END// +ERROR HY000: Unknown system variable 'v' +SET @old_init_connect= @@GLOBAL.init_connect; +CALL p5(); +@@SESSION.IDENTITY +1 +@@GLOBAL.init_connect +SELECT 1 +init_connect +10 +SET @@GLOBAL.init_connect= @old_init_connect; +DROP PROCEDURE p2; +DROP PROCEDURE p5; # ------------------------------------------------------------------ # -- End of 5.1 tests # ------------------------------------------------------------------ -- cgit v1.2.1 From a120e969a83128f075b54a06155ccee0bb46b312 Mon Sep 17 00:00:00 2001 From: Jorgen Loland Date: Fri, 13 Nov 2009 12:22:39 +0100 Subject: Bug#48052: Valgrind warning - uninitialized value in init_read_record() - (records.cc:274) Item_cond::used_tables_cache was accessed in records.cc#init_read_record() without being initialized. It had not been initialized because it was wrongly assumed that the Item's variables would not be accessed, and hence quick_fix_field() was used instead of fix_fields() to save a few CPU cycles at creation time. The fix is to properly initilize the Item by replacing quick_fix_field() with fix_fields(). mysql-test/r/select.result: Add test for BUG#48052 mysql-test/t/select.test: Add test for BUG#48052 sql/sql_select.cc: Properly initialize Item_cond_and by calling fix_fields (instead of quick_fix_field) when the Item that "ANDs" WHERE clause conditions with HAVING clause conditions is created. --- mysql-test/r/select.result | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/select.result b/mysql-test/r/select.result index e528b63ddb7..d0b2a575a32 100644 --- a/mysql-test/r/select.result +++ b/mysql-test/r/select.result @@ -4591,4 +4591,22 @@ field2 15:13:38 drop table A,AA,B,BB; #end of test for bug#45266 +# +# BUG#48052: Valgrind warning - uninitialized value in init_read_record() +# +CREATE TABLE t1 ( +pk int(11) NOT NULL, +i int(11) DEFAULT NULL, +v varchar(1) DEFAULT NULL, +PRIMARY KEY (pk) +); +INSERT INTO t1 VALUES (2,7,'m'); +INSERT INTO t1 VALUES (3,9,'m'); +SELECT v +FROM t1 +WHERE NOT pk > 0 +HAVING v <= 't' +ORDER BY pk; +v +DROP TABLE t1; End of 5.1 tests -- cgit v1.2.1 From bc43bff7edf79095c243cf6858acb29213fb152b Mon Sep 17 00:00:00 2001 From: Evgeny Potemkin Date: Tue, 17 Nov 2009 17:06:46 +0300 Subject: Bug#43668: Wrong comparison and MIN/MAX for YEAR(2) MySQL manual describes values of the YEAR(2) field type as follows: values 00 - 69 mean 2000 - 2069 years and values 70 - 99 mean 1970 - 1999 years. MIN/MAX and comparison functions was comparing them as int values thus producing wrong result. Now the Arg_comparator class is extended with compare_year function which performs correct comparison of the YEAR type. The Item_sum_hybrid class now uses Item_cache and Arg_comparator objects to correctly calculate its value. To allow Arg_comparator to use func_name() function for Item_func and Item_sum objects the func_name declaration is moved to the Item_result_field class. A helper function is_owner_equal_func is added to the Arg_comparator class. It checks whether the Arg_comparator object owner is the <=> function or not. A helper function setup is added to the Item_sum_hybrid class. It sets up cache item and comparator. mysql-test/r/func_group.result: Added a test case for the bug#43668. mysql-test/t/func_group.test: Added a test case for the bug#43668. sql/item.cc: Bug#43668: Wrong comparison and MIN/MAX for YEAR(2) Now Item_cache_int returns the type of cached item. sql/item.h: Bug#43668: Wrong comparison and MIN/MAX for YEAR(2) To allow Arg_comparator to use func_name() function for Item_func and Item_sum objects the func_name declaration is moved to the Item_result_field class. sql/item_cmpfunc.cc: Bug#43668: Wrong comparison and MIN/MAX for YEAR(2) The Arg_comparator class is extended with compare_year function which performs correct comparison of the YEAR type. sql/item_cmpfunc.h: Bug#43668: Wrong comparison and MIN/MAX for YEAR(2) The year_as_datetime variable is added to the Arg_comparator class. It's set to TRUE when YEAR value should be converted to the YYYY-00-00 00:00:00 format for correct YEAR-DATETIME comparison. sql/item_geofunc.cc: Bug#43668: Wrong comparison and MIN/MAX for YEAR(2) Item_func_spatial_rel::val_int chenged to use Arg_comparator's string buffers. sql/item_subselect.h: Bug#43668: Wrong comparison and MIN/MAX for YEAR(2) Added an implementation of the virtual func_name function. sql/item_sum.cc: Bug#43668: Wrong comparison and MIN/MAX for YEAR(2) The Item_sum_hybrid class now uses Item_cache and Arg_comparator objects to correctly calculate its value. A helper function setup is added to the Item_sum_hybrid class. It sets up cache item and comparator. sql/item_sum.h: Bug#43668: Wrong comparison and MIN/MAX for YEAR(2) The Item_sum_hybrid class now uses Item_cache and Arg_comparator objects to correctly calculate its value. Added an implementation of the virtual func_name function. --- mysql-test/r/func_group.result | 195 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 194 insertions(+), 1 deletion(-) (limited to 'mysql-test/r') diff --git a/mysql-test/r/func_group.result b/mysql-test/r/func_group.result index 3d989ad1730..b0877991367 100644 --- a/mysql-test/r/func_group.result +++ b/mysql-test/r/func_group.result @@ -885,7 +885,7 @@ cast(sum(distinct df) as signed) 3 select cast(min(df) as signed) from t1; cast(min(df) as signed) -0 +1 select 1e8 * sum(distinct df) from t1; 1e8 * sum(distinct df) 330000000 @@ -1477,3 +1477,196 @@ COUNT(*) SET SQL_MODE=default; DROP TABLE t1; End of 5.0 tests +# +# Bug#43668: Wrong comparison and MIN/MAX for YEAR(2) +# +create table t1 (f1 year(2), f2 year(4), f3 date, f4 datetime); +insert into t1 values +(98,1998,19980101,"1998-01-01 00:00:00"), +(00,2000,20000101,"2000-01-01 00:00:01"), +(02,2002,20020101,"2002-01-01 23:59:59"), +(60,2060,20600101,"2060-01-01 11:11:11"), +(70,1970,19700101,"1970-11-11 22:22:22"), +(NULL,NULL,NULL,NULL); +select min(f1),max(f1) from t1; +min(f1) max(f1) +70 60 +select min(f2),max(f2) from t1; +min(f2) max(f2) +1970 2060 +select min(f3),max(f3) from t1; +min(f3) max(f3) +1970-01-01 2060-01-01 +select min(f4),max(f4) from t1; +min(f4) max(f4) +1970-11-11 22:22:22 2060-01-01 11:11:11 +select a.f1 as a, b.f1 as b, a.f1 > b.f1 as gt, +a.f1 < b.f1 as lt, a.f1<=>b.f1 as eq +from t1 a, t1 b; +a b gt lt eq +98 98 0 0 1 +00 98 1 0 0 +02 98 1 0 0 +60 98 1 0 0 +70 98 0 1 0 +NULL 98 NULL NULL 0 +98 00 0 1 0 +00 00 0 0 1 +02 00 1 0 0 +60 00 1 0 0 +70 00 0 1 0 +NULL 00 NULL NULL 0 +98 02 0 1 0 +00 02 0 1 0 +02 02 0 0 1 +60 02 1 0 0 +70 02 0 1 0 +NULL 02 NULL NULL 0 +98 60 0 1 0 +00 60 0 1 0 +02 60 0 1 0 +60 60 0 0 1 +70 60 0 1 0 +NULL 60 NULL NULL 0 +98 70 1 0 0 +00 70 1 0 0 +02 70 1 0 0 +60 70 1 0 0 +70 70 0 0 1 +NULL 70 NULL NULL 0 +98 NULL NULL NULL 0 +00 NULL NULL NULL 0 +02 NULL NULL NULL 0 +60 NULL NULL NULL 0 +70 NULL NULL NULL 0 +NULL NULL NULL NULL 1 +select a.f1 as a, b.f2 as b, a.f1 > b.f2 as gt, +a.f1 < b.f2 as lt, a.f1<=>b.f2 as eq +from t1 a, t1 b; +a b gt lt eq +98 1998 0 0 1 +00 1998 1 0 0 +02 1998 1 0 0 +60 1998 1 0 0 +70 1998 0 1 0 +NULL 1998 NULL NULL 0 +98 2000 0 1 0 +00 2000 0 0 1 +02 2000 1 0 0 +60 2000 1 0 0 +70 2000 0 1 0 +NULL 2000 NULL NULL 0 +98 2002 0 1 0 +00 2002 0 1 0 +02 2002 0 0 1 +60 2002 1 0 0 +70 2002 0 1 0 +NULL 2002 NULL NULL 0 +98 2060 0 1 0 +00 2060 0 1 0 +02 2060 0 1 0 +60 2060 0 0 1 +70 2060 0 1 0 +NULL 2060 NULL NULL 0 +98 1970 1 0 0 +00 1970 1 0 0 +02 1970 1 0 0 +60 1970 1 0 0 +70 1970 0 0 1 +NULL 1970 NULL NULL 0 +98 NULL NULL NULL 0 +00 NULL NULL NULL 0 +02 NULL NULL NULL 0 +60 NULL NULL NULL 0 +70 NULL NULL NULL 0 +NULL NULL NULL NULL 1 +select a.f1 as a, b.f3 as b, a.f1 > b.f3 as gt, +a.f1 < b.f3 as lt, a.f1<=>b.f3 as eq +from t1 a, t1 b; +a b gt lt eq +98 1998-01-01 0 1 0 +00 1998-01-01 1 0 0 +02 1998-01-01 1 0 0 +60 1998-01-01 1 0 0 +70 1998-01-01 0 1 0 +NULL 1998-01-01 NULL NULL 0 +98 2000-01-01 0 1 0 +00 2000-01-01 0 1 0 +02 2000-01-01 1 0 0 +60 2000-01-01 1 0 0 +70 2000-01-01 0 1 0 +NULL 2000-01-01 NULL NULL 0 +98 2002-01-01 0 1 0 +00 2002-01-01 0 1 0 +02 2002-01-01 0 1 0 +60 2002-01-01 1 0 0 +70 2002-01-01 0 1 0 +NULL 2002-01-01 NULL NULL 0 +98 2060-01-01 0 1 0 +00 2060-01-01 0 1 0 +02 2060-01-01 0 1 0 +60 2060-01-01 0 1 0 +70 2060-01-01 0 1 0 +NULL 2060-01-01 NULL NULL 0 +98 1970-01-01 1 0 0 +00 1970-01-01 1 0 0 +02 1970-01-01 1 0 0 +60 1970-01-01 1 0 0 +70 1970-01-01 0 1 0 +NULL 1970-01-01 NULL NULL 0 +98 NULL NULL NULL 0 +00 NULL NULL NULL 0 +02 NULL NULL NULL 0 +60 NULL NULL NULL 0 +70 NULL NULL NULL 0 +NULL NULL NULL NULL 1 +select a.f1 as a, b.f4 as b, a.f1 > b.f4 as gt, +a.f1 < b.f4 as lt, a.f1<=>b.f4 as eq +from t1 a, t1 b; +a b gt lt eq +98 1998-01-01 00:00:00 0 1 0 +00 1998-01-01 00:00:00 1 0 0 +02 1998-01-01 00:00:00 1 0 0 +60 1998-01-01 00:00:00 1 0 0 +70 1998-01-01 00:00:00 0 1 0 +NULL 1998-01-01 00:00:00 NULL NULL 0 +98 2000-01-01 00:00:01 0 1 0 +00 2000-01-01 00:00:01 0 1 0 +02 2000-01-01 00:00:01 1 0 0 +60 2000-01-01 00:00:01 1 0 0 +70 2000-01-01 00:00:01 0 1 0 +NULL 2000-01-01 00:00:01 NULL NULL 0 +98 2002-01-01 23:59:59 0 1 0 +00 2002-01-01 23:59:59 0 1 0 +02 2002-01-01 23:59:59 0 1 0 +60 2002-01-01 23:59:59 1 0 0 +70 2002-01-01 23:59:59 0 1 0 +NULL 2002-01-01 23:59:59 NULL NULL 0 +98 2060-01-01 11:11:11 0 1 0 +00 2060-01-01 11:11:11 0 1 0 +02 2060-01-01 11:11:11 0 1 0 +60 2060-01-01 11:11:11 0 1 0 +70 2060-01-01 11:11:11 0 1 0 +NULL 2060-01-01 11:11:11 NULL NULL 0 +98 1970-11-11 22:22:22 1 0 0 +00 1970-11-11 22:22:22 1 0 0 +02 1970-11-11 22:22:22 1 0 0 +60 1970-11-11 22:22:22 1 0 0 +70 1970-11-11 22:22:22 0 1 0 +NULL 1970-11-11 22:22:22 NULL NULL 0 +98 NULL NULL NULL 0 +00 NULL NULL NULL 0 +02 NULL NULL NULL 0 +60 NULL NULL NULL 0 +70 NULL NULL NULL 0 +NULL NULL NULL NULL 1 +select *, f1 = f2 from t1; +f1 f2 f3 f4 f1 = f2 +98 1998 1998-01-01 1998-01-01 00:00:00 1 +00 2000 2000-01-01 2000-01-01 00:00:01 1 +02 2002 2002-01-01 2002-01-01 23:59:59 1 +60 2060 2060-01-01 2060-01-01 11:11:11 1 +70 1970 1970-01-01 1970-11-11 22:22:22 1 +NULL NULL NULL NULL NULL +drop table t1; +# -- cgit v1.2.1 From 8cfa50e6771f1dbd6f265be44d9340a7d53084c2 Mon Sep 17 00:00:00 2001 From: Alexey Kopytov Date: Tue, 17 Nov 2009 17:07:14 +0300 Subject: Bug #48472: Loose index scan inappropriately chosen for some WHERE conditions check_group_min_max() checks if the loose index scan optimization is applicable for a given WHERE condition, that is if the MIN/MAX attribute participates only in range predicates comparing the corresponding field with constants. The problem was that it considered the whole predicate suitable for the loose index scan optimization as soon as it encountered a constant as a predicate argument. This is obviously wrong for cases when a constant is the first argument of a predicate which does not satisfy the above condition. Fixed check_group_min_max() so that all arguments of the input predicate are considered to decide if it passes the test, even though a constant has already been encountered. mysql-test/r/group_min_max.result: Added a test case for bug #48472. mysql-test/t/group_min_max.test: Added a test case for bug #48472. sql/opt_range.cc: Fixed check_group_min_max() so that all arguments of the input predicate are considered to decide if it passes the test, even though a constant has already been encountered. --- mysql-test/r/group_min_max.result | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/group_min_max.result b/mysql-test/r/group_min_max.result index 9acbbaac499..46076fb288d 100644 --- a/mysql-test/r/group_min_max.result +++ b/mysql-test/r/group_min_max.result @@ -2480,4 +2480,15 @@ SELECT a, MAX(b) FROM t WHERE b > 0 AND b < 2 GROUP BY a; a MAX(b) 2 1 DROP TABLE t; +# +# Bug #48472: Loose index scan inappropriately chosen for some WHERE +# conditions +# +CREATE TABLE t (a INT, b INT, INDEX (a,b)); +INSERT INTO t VALUES (2,0), (2,0), (2,1), (2,1); +INSERT INTO t SELECT * FROM t; +SELECT a, MAX(b) FROM t WHERE 0=b+0 GROUP BY a; +a MAX(b) +2 0 +DROP TABLE t; End of 5.0 tests -- cgit v1.2.1 From 98fd304278ca029b56671412e8bec72ed4f17537 Mon Sep 17 00:00:00 2001 From: Mattias Jonsson Date: Tue, 17 Nov 2009 22:47:34 +0100 Subject: backport of bug#45904 from mysql-pe to 5.1 sql/sql_partition.cc: Bug#45904 Used list_of_part_fields instead of list_of_subpart_fields to discover if KEY subpartitioning => caused failure when charset=utf8 even for subpartitioning by key, would also allow for subpartitioning by hash with utf8 erroneously --- mysql-test/r/partition.result | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/partition.result b/mysql-test/r/partition.result index 6611d39628f..425f1e85d00 100644 --- a/mysql-test/r/partition.result +++ b/mysql-test/r/partition.result @@ -50,6 +50,13 @@ t1 CREATE TABLE `t1` ( PARTITION p3 VALUES LESS THAN (733969) ENGINE = MyISAM, PARTITION pmax VALUES LESS THAN MAXVALUE ENGINE = MyISAM) */ DROP TABLE t1; +create table t1 (a int NOT NULL, b varchar(5) NOT NULL) +default charset=utf8 +partition by list (a) +subpartition by key (b) +(partition p0 values in (1), +partition p1 values in (2)); +drop table t1; create table t1 (a int, b int, key(a)) partition by list (a) ( partition p0 values in (1), -- cgit v1.2.1 From 41ba42928628fc555cb2f222fbacefa178f63f0a Mon Sep 17 00:00:00 2001 From: Jon Olav Hauglid Date: Wed, 18 Nov 2009 10:02:21 +0100 Subject: Bug #47682 strange behaviour of INSERT DELAYED The problem was a "self-deadlock" if the connection issuing INSERT DELAYED had both the global read lock (FLUSH TABLES WITH READ LOCK) and LOCK TABLES mode active. The table being inserted into had to be different from the table(s) locked by LOCK TABLES. For INSERT DELAYED, the connection thread waits until the handler thread has opened and locked its table before returning. But since the global read lock was active, the handler thread would be unable to lock and would wait for the global read lock to go away. So the handler thread would be waiting for the connection thread to release the global read lock while the connection thread was waiting for the handler thread to lock the table. This gave a "self-deadlock" (same connection, different threads). The deadlock would only happen if we also had LOCK TABLES mode since the INSERT otherwise will try to get protection against global read lock before starting the handler thread. It will then notice that the global read lock is owned by the same connection and report ER_CANT_UPDATE_WITH_READLOCK. This patch removes the deadlock by reporting ER_CANT_UPDATE_WITH_READLOCK also if we are inside LOCK TABLES mode. Test case added to delayed.test. --- mysql-test/r/delayed.result | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/delayed.result b/mysql-test/r/delayed.result index 4d5d656f3ce..11156b0f883 100644 --- a/mysql-test/r/delayed.result +++ b/mysql-test/r/delayed.result @@ -310,4 +310,16 @@ a b 2 2 drop table t1; set global low_priority_updates = @old_delayed_updates; +# +# Bug #47682 strange behaviour of INSERT DELAYED +# +DROP TABLE IF EXISTS t1, t2; +CREATE TABLE t1 (f1 integer); +CREATE TABLE t2 (f1 integer); +FLUSH TABLES WITH READ LOCK; +LOCK TABLES t1 READ; +INSERT DELAYED INTO t2 VALUES (1); +ERROR HY000: Can't execute the query because you have a conflicting read lock +UNLOCK TABLES; +DROP TABLE t1, t2; End of 5.1 tests -- cgit v1.2.1 From 3987c7ac4b7ecfde471c10386bb413205809dfe1 Mon Sep 17 00:00:00 2001 From: Magne Mahre Date: Wed, 18 Nov 2009 10:32:03 +0100 Subject: Bug #46425 crash in Diagnostics_area::set_ok_status , empty statement, DELETE IGNORE The ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG error was set in the diagnostics area when it happened, but the DELETE cleanup code never checked for a non-fatal error condition, thus trying to set diag.area to "ok". This triggered an assert checking that the diag.area was empty. The fix was to test if there existed a non-fatal error condition (thd->is_error() before ok'ing the operation. --- mysql-test/r/delete.result | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/delete.result b/mysql-test/r/delete.result index 0124a7da35a..1df19a75854 100644 --- a/mysql-test/r/delete.result +++ b/mysql-test/r/delete.result @@ -324,3 +324,16 @@ a 1 2 DROP TABLE t1, t2, t3; +# +# Bug #46425 crash in Diagnostics_area::set_ok_status, +# empty statement, DELETE IGNORE +# +CREATE table t1 (i INTEGER); +INSERT INTO t1 VALUES (1); +CREATE TRIGGER tr1 AFTER DELETE ON t1 FOR EACH ROW +BEGIN +INSERT INTO t1 SELECT * FROM t1 AS A; +END | +DELETE IGNORE FROM t1; +ERROR HY000: Can't update table 't1' in stored function/trigger because it is already used by statement which invoked this stored function/trigger. +DROP TABLE t1; -- cgit v1.2.1 From 7524b96102bcfeb7366b88d307bb53e9fe8c309f Mon Sep 17 00:00:00 2001 From: Jon Olav Hauglid Date: Wed, 18 Nov 2009 13:49:45 +0100 Subject: Postfix for Bug #47682 strange behaviour of INSERT DELAYED Fixed a problem with the test case when executed with ps-protocol. There the conflicing lock would be noticed during prepare, not during execution of the insert - leading to a different (but equally appropriate) error message. --- mysql-test/r/delayed.result | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'mysql-test/r') diff --git a/mysql-test/r/delayed.result b/mysql-test/r/delayed.result index 11156b0f883..d8048a703a2 100644 --- a/mysql-test/r/delayed.result +++ b/mysql-test/r/delayed.result @@ -319,7 +319,7 @@ CREATE TABLE t2 (f1 integer); FLUSH TABLES WITH READ LOCK; LOCK TABLES t1 READ; INSERT DELAYED INTO t2 VALUES (1); -ERROR HY000: Can't execute the query because you have a conflicting read lock +Got one of the listed errors UNLOCK TABLES; DROP TABLE t1, t2; End of 5.1 tests -- cgit v1.2.1 From 405c9310cfe2cf4673f5fb66dc221016b4e92ed6 Mon Sep 17 00:00:00 2001 From: Georgi Kodinov Date: Thu, 19 Nov 2009 18:26:19 +0200 Subject: Bug #48665: sql-bench's insert test fails due to wrong result When merging ranges during calculation of the result of OR to two range sets the current range may be obsoleted by the resulting merged range. The first overlapping range can be obsoleted as well. Fixed by moving the pointer to the first overlapping range to the pointer of the resulting union range. Added few comments at key places in key_or(). --- mysql-test/r/range.result | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/range.result b/mysql-test/r/range.result index 2306f8b501e..ab40eefdc82 100644 --- a/mysql-test/r/range.result +++ b/mysql-test/r/range.result @@ -1603,4 +1603,21 @@ SELECT str_to_date('', '%Y-%m-%d'); str_to_date('', '%Y-%m-%d') 0000-00-00 DROP TABLE t1, t2; +# +# Bug #48665: sql-bench's insert test fails due to wrong result +# +CREATE TABLE t1 (a INT, b INT, PRIMARY KEY (a)); +INSERT INTO t1 VALUES (0,0), (1,1); +EXPLAIN +SELECT * FROM t1 FORCE INDEX (PRIMARY) +WHERE (a>=1 AND a<=2) OR (a>=4 AND a<=5) OR (a>=0 AND a <=10); +id select_type table type possible_keys key key_len ref rows Extra +@ @ @ range @ @ @ @ @ @ +# Should return 2 rows +SELECT * FROM t1 FORCE INDEX (PRIMARY) +WHERE (a>=1 AND a<=2) OR (a>=4 AND a<=5) OR (a>=0 AND a <=10); +a b +0 0 +1 1 +DROP TABLE t1; End of 5.1 tests -- cgit v1.2.1 From a21cd97c3506a70297afc3dd3f64cdfd2dc0a4e6 Mon Sep 17 00:00:00 2001 From: Georgi Kodinov Date: Fri, 20 Nov 2009 12:10:47 +0200 Subject: Bug #45261 : Crash, stored procedure + decimal Bug #48370 Absolutely wrong calculations with GROUP BY and decimal fields when using IF Added the test cases in the above two bugs for regression testing. Added additional tests that demonstrate a incomplete fix. Added a new factory method for Field_new_decimal to create a field from an (decimal returning) Item. In the new method made sure that all the precision and length variables are capped in a proper way. This is required because Item's can have larger precision than the decimal fields and thus need to be capped when creating a field based on an Item type. Fixed the wrong typecast to Item_decimal. --- mysql-test/r/type_newdecimal.result | 284 ++++++++++++++++++++++++++++++++++++ 1 file changed, 284 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/type_newdecimal.result b/mysql-test/r/type_newdecimal.result index 748aadee4fb..70ee3a56cf3 100644 --- a/mysql-test/r/type_newdecimal.result +++ b/mysql-test/r/type_newdecimal.result @@ -1630,3 +1630,287 @@ SELECT my_col FROM t1; my_col 0.012345687012345687012345687012 DROP TABLE t1; +# +# Bug#45261: Crash, stored procedure + decimal +# +DROP TABLE IF EXISTS t1; +CREATE TABLE t1 SELECT +/* 81 */ 100000000000000000000000000000000000000000000000000000000000000000000000000000001 +AS c1; +Warnings: +Warning 1264 Out of range value for column 'c1' at row 1 +DESC t1; +Field Type Null Key Default Extra +c1 decimal(65,0) NO 0 +SELECT * FROM t1; +c1 +99999999999999999999999999999999999999999999999999999999999999999 +DROP TABLE t1; +CREATE TABLE t1 SELECT +/* 81 */ 100000000000000000000000000000000000000000000000000000000000000000000000000000001. +AS c1; +Warnings: +Warning 1264 Out of range value for column 'c1' at row 1 +DESC t1; +Field Type Null Key Default Extra +c1 decimal(65,0) NO 0 +SELECT * FROM t1; +c1 +99999999999999999999999999999999999999999999999999999999999999999 +DROP TABLE t1; +CREATE TABLE t1 SELECT +/* 81 */ 100000000000000000000000000000000000000000000000000000000000000000000000000000001.1 /* 1 */ +AS c1; +Warnings: +Warning 1264 Out of range value for column 'c1' at row 1 +DESC t1; +Field Type Null Key Default Extra +c1 decimal(65,0) NO 0 +SELECT * FROM t1; +c1 +99999999999999999999999999999999999999999999999999999999999999999 +DROP TABLE t1; +CREATE TABLE t1 SELECT +/* 82 */ 1000000000000000000000000000000000000000000000000000000000000000000000000000000001 +AS c1; +Warnings: +Error 1292 Truncated incorrect DECIMAL value: '' +DESC t1; +Field Type Null Key Default Extra +c1 decimal(65,0) NO 0 +SELECT * FROM t1; +c1 +99999999999999999999999999999999999999999999999999999999999999999 +DROP TABLE t1; +CREATE TABLE t1 SELECT +/* 40 */ 1000000000000000000000000000000000000001.1000000000000000000000000000000000000001 /* 40 */ +AS c1; +Warnings: +Warning 1264 Out of range value for column 'c1' at row 1 +DESC t1; +Field Type Null Key Default Extra +c1 decimal(65,30) NO 0.000000000000000000000000000000 +SELECT * FROM t1; +c1 +99999999999999999999999999999999999.999999999999999999999999999999 +DROP TABLE t1; +CREATE TABLE t1 SELECT +/* 1 */ 1.10000000000000000000000000000000000000000000000000000000000000000000000000000001 /* 80 */ +AS c1; +DESC t1; +Field Type Null Key Default Extra +c1 decimal(31,30) NO 0.000000000000000000000000000000 +SELECT * FROM t1; +c1 +1.100000000000000000000000000000 +DROP TABLE t1; +CREATE TABLE t1 SELECT +/* 1 */ 1.100000000000000000000000000000000000000000000000000000000000000000000000000000001 /* 81 */ +AS c1; +DESC t1; +Field Type Null Key Default Extra +c1 decimal(31,30) NO 0.000000000000000000000000000000 +SELECT * FROM t1; +c1 +1.100000000000000000000000000000 +DROP TABLE t1; +CREATE TABLE t1 SELECT +.100000000000000000000000000000000000000000000000000000000000000000000000000000001 /* 81 */ +AS c1; +Warnings: +Note 1265 Data truncated for column 'c1' at row 1 +DESC t1; +Field Type Null Key Default Extra +c1 decimal(30,30) NO 0.000000000000000000000000000000 +SELECT * FROM t1; +c1 +0.100000000000000000000000000000 +DROP TABLE t1; +CREATE TABLE t1 SELECT +/* 45 */ 123456789012345678901234567890123456789012345.123456789012345678901234567890123456789012345 /* 45 */ +AS c1; +Warnings: +Warning 1264 Out of range value for column 'c1' at row 1 +DESC t1; +Field Type Null Key Default Extra +c1 decimal(65,30) NO 0.000000000000000000000000000000 +SELECT * FROM t1; +c1 +99999999999999999999999999999999999.999999999999999999999999999999 +DROP TABLE t1; +CREATE TABLE t1 SELECT +/* 65 */ 12345678901234567890123456789012345678901234567890123456789012345.1 /* 1 */ +AS c1; +Warnings: +Warning 1264 Out of range value for column 'c1' at row 1 +DESC t1; +Field Type Null Key Default Extra +c1 decimal(65,1) NO 0.0 +SELECT * FROM t1; +c1 +9999999999999999999999999999999999999999999999999999999999999999.9 +DROP TABLE t1; +CREATE TABLE t1 SELECT +/* 66 */ 123456789012345678901234567890123456789012345678901234567890123456.1 /* 1 */ +AS c1; +Warnings: +Warning 1264 Out of range value for column 'c1' at row 1 +DESC t1; +Field Type Null Key Default Extra +c1 decimal(65,1) NO 0.0 +SELECT * FROM t1; +c1 +9999999999999999999999999999999999999999999999999999999999999999.9 +DROP TABLE t1; +CREATE TABLE t1 SELECT +.123456789012345678901234567890123456789012345678901234567890123456 /* 66 */ +AS c1; +Warnings: +Note 1265 Data truncated for column 'c1' at row 1 +DESC t1; +Field Type Null Key Default Extra +c1 decimal(30,30) NO 0.000000000000000000000000000000 +SELECT * FROM t1; +c1 +0.123456789012345678901234567890 +DROP TABLE t1; +CREATE TABLE t1 AS SELECT 123.1234567890123456789012345678901 /* 31 */ AS c1; +Warnings: +Note 1265 Data truncated for column 'c1' at row 1 +DESC t1; +Field Type Null Key Default Extra +c1 decimal(33,30) NO 0.000000000000000000000000000000 +SELECT * FROM t1; +c1 +123.123456789012345678901234567890 +DROP TABLE t1; +CREATE TABLE t1 SELECT 1.1 + CAST(1 AS DECIMAL(65,30)) AS c1; +DESC t1; +Field Type Null Key Default Extra +c1 decimal(65,30) NO 0.000000000000000000000000000000 +SELECT * FROM t1; +c1 +2.100000000000000000000000000000 +DROP TABLE t1; +# +# Test that the integer and decimal parts are properly calculated. +# +CREATE TABLE t1 (a DECIMAL(30,30)); +INSERT INTO t1 VALUES (0.1),(0.2),(0.3); +CREATE TABLE t2 SELECT MIN(a + 0.0000000000000000000000000000001) AS c1 FROM t1; +Warnings: +Note 1265 Data truncated for column 'c1' at row 3 +DESC t2; +Field Type Null Key Default Extra +c1 decimal(32,30) YES NULL +DROP TABLE t1,t2; +CREATE TABLE t1 (a DECIMAL(30,30)); +INSERT INTO t1 VALUES (0.1),(0.2),(0.3); +CREATE TABLE t2 SELECT IFNULL(a + 0.0000000000000000000000000000001, NULL) AS c1 FROM t1; +Warnings: +Note 1265 Data truncated for column 'c1' at row 1 +Note 1265 Data truncated for column 'c1' at row 2 +Note 1265 Data truncated for column 'c1' at row 3 +DESC t2; +Field Type Null Key Default Extra +c1 decimal(34,0) YES NULL +DROP TABLE t1,t2; +CREATE TABLE t1 (a DECIMAL(30,30)); +INSERT INTO t1 VALUES (0.1),(0.2),(0.3); +CREATE TABLE t2 SELECT CASE a WHEN 0.1 THEN 0.0000000000000000000000000000000000000000000000000000000000000000001 END AS c1 FROM t1; +Warnings: +Note 1265 Data truncated for column 'c1' at row 1 +DESC t2; +Field Type Null Key Default Extra +c1 decimal(65,30) YES NULL +DROP TABLE t1,t2; +# +# Test that variables get maximum precision. +# +SET @decimal= 1.1; +CREATE TABLE t1 SELECT @decimal AS c1; +DESC t1; +Field Type Null Key Default Extra +c1 decimal(65,30) YES NULL +SELECT * FROM t1; +c1 +1.100000000000000000000000000000 +DROP TABLE t1; +# +# Bug #45261 : Crash, stored procedure + decimal +# Original test by the reporter. +# +# should not crash +CREATE TABLE t1 +SELECT .123456789012345678901234567890123456789012345678901234567890123456 AS a; +Warnings: +Note 1265 Data truncated for column 'a' at row 1 +DROP TABLE t1; +CREATE PROCEDURE test_proc() +BEGIN +# The las non critical CUSER definition is: +# DECLARE mycursor CURSOR FOR SELECT 1 % +# .12345678912345678912345678912345678912345678912345678912345678912 AS my_col; +DECLARE mycursor CURSOR FOR +SELECT 1 % +.123456789123456789123456789123456789123456789123456789123456789123456789123456789 +AS my_col; +OPEN mycursor; +CLOSE mycursor; +END| +# should not crash +CALL test_proc(); +DROP PROCEDURE test_proc; +# +# Bug #48370 Absolutely wrong calculations with GROUP BY and +# decimal fields when using IF +# +CREATE TABLE currencies (id int, rate decimal(16,4), +PRIMARY KEY (id), KEY (rate)); +INSERT INTO currencies VALUES (11,0.7028); +INSERT INTO currencies VALUES (1,1); +CREATE TABLE payments ( +id int, +supplier_id int, +status int, +currency_id int, +vat decimal(7,4), +PRIMARY KEY (id), +KEY currency_id (currency_id), +KEY supplier_id (supplier_id) +); +INSERT INTO payments (id,status,vat,supplier_id,currency_id) VALUES +(3001,2,0.0000,344,11), (1,2,0.0000,1,1); +CREATE TABLE sub_tasks ( +id int, +currency_id int, +price decimal(16,4), +discount decimal(10,4), +payment_id int, +PRIMARY KEY (id), +KEY currency_id (currency_id), +KEY payment_id (payment_id) +) ; +INSERT INTO sub_tasks (id, price, discount, payment_id, currency_id) VALUES +(52, 12.60, 0, 3001, 11), (56, 14.58, 0, 3001, 11); +# should return 1 and the same values in col 2 and 3 +select STRAIGHT_JOIN +(1 + PAY.vat) AS mult, +SUM(ROUND((SUB.price - ROUND(ROUND(SUB.price, 2) * SUB.discount, 2)) * +CUR.rate / CUR.rate, 2) +) v_net_with_discount, +SUM(ROUND((SUB.price - ROUND(ROUND(SUB.price, 2) * SUB.discount, 1)) * +CUR.rate / CUR.rate , 2) +* (1 + PAY.vat) +) v_total +from +currencies CUR, payments PAY, sub_tasks SUB +where +SUB.payment_id = PAY.id and +PAY.currency_id = CUR.id and +PAY.id > 2 +group by PAY.id + 1; +mult v_net_with_discount v_total +1.0000 27.18 27.180000 +DROP TABLE currencies, payments, sub_tasks; +End of 5.1 tests -- cgit v1.2.1 From c70a9fa1e3c459e030546b0ca1ac916970bb489b Mon Sep 17 00:00:00 2001 From: Davi Arnaut Date: Sat, 21 Nov 2009 09:18:21 -0200 Subject: Bug#41726: upgrade from 5.0 to 5.1.30 crashes if you didn't run mysql_upgrade The problem is that the server could crash when attempting to access a non-conformant proc system table. One such case was a crash when invoking stored procedure related statements on a 5.1 server with a proc system table in the 5.0 format. The solution is to validate the proc system table format before attempts to access it are made. If the table is not in the format that the server expects, a message is written to the error log and the statement that caused the table to be accessed fails. mysql-test/r/sp-destruct.result: Add test case result for Bug#41726 mysql-test/t/sp-destruct.test: Add test case for Bug#41726 sql/event_db_repository.cc: Update code to use new structures. sql/sp.cc: Describe the proc table format and use it to validate when opening a instance of the table. Add a check to insure that a error message is written to the error log only once. sql/sql_acl.cc: Remove unused variable and use new structure. sql/sql_acl.h: Export field definition. sql/table.cc: Accept the field count and definition in a single structure. sql/table.h: Combine the field count and definition in a single structure. Transform function into a class in order to support different ways of reporting a error. Add a pointer cache to TABLE_SHARE. --- mysql-test/r/sp-destruct.result | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-) (limited to 'mysql-test/r') diff --git a/mysql-test/r/sp-destruct.result b/mysql-test/r/sp-destruct.result index d7d44061b76..b6891df2420 100644 --- a/mysql-test/r/sp-destruct.result +++ b/mysql-test/r/sp-destruct.result @@ -1,3 +1,4 @@ +call mtr.add_suppression("Column count of mysql.proc is wrong. Expected 20, found 19. The table is probably corrupted"); use test; drop procedure if exists bug14233; drop function if exists bug14233; @@ -11,11 +12,13 @@ create table t1 (id int); create trigger t1_ai after insert on t1 for each row call bug14233(); alter table mysql.proc drop type; call bug14233(); -ERROR HY000: Failed to load routine test.bug14233. The table mysql.proc is missing, corrupt, or contains bad data (internal code -5) +ERROR HY000: Column count of mysql.proc is wrong. Expected 20, found 19. The table is probably corrupted create view v1 as select bug14233_f(); -ERROR HY000: Failed to load routine test.bug14233_f. The table mysql.proc is missing, corrupt, or contains bad data (internal code -5) +ERROR HY000: Column count of mysql.proc is wrong. Expected 20, found 19. The table is probably corrupted insert into t1 values (0); -ERROR HY000: Failed to load routine test.bug14233. The table mysql.proc is missing, corrupt, or contains bad data (internal code -5) +ERROR HY000: Column count of mysql.proc is wrong. Expected 20, found 19. The table is probably corrupted +show procedure status; +ERROR HY000: Column count of mysql.proc is wrong. Expected 20, found 19. The table is probably corrupted flush table mysql.proc; call bug14233(); ERROR HY000: Incorrect information in file: './mysql/proc.frm' @@ -88,3 +91,28 @@ show procedure status where db=DATABASE(); Db Name Type Definer Modified Created Security_type Comment character_set_client collation_connection Database Collation show function status where db=DATABASE(); Db Name Type Definer Modified Created Security_type Comment character_set_client collation_connection Database Collation +DROP TABLE IF EXISTS proc_backup; +DROP PROCEDURE IF EXISTS p1; +# Backup the proc table +RENAME TABLE mysql.proc TO proc_backup; +CREATE TABLE mysql.proc LIKE proc_backup; +FLUSH TABLE mysql.proc; +# Test with a valid table. +CREATE PROCEDURE p1() +SET @foo = 10; +CALL p1(); +SHOW PROCEDURE STATUS; +Db Name Type Definer Modified Created Security_type Comment character_set_client collation_connection Database Collation +test p1 PROCEDURE root@localhost 0000-00-00 00:00:00 0000-00-00 00:00:00 DEFINER latin1 latin1_swedish_ci latin1_swedish_ci +# Modify a field of the table. +ALTER TABLE mysql.proc MODIFY comment CHAR (32); +CREATE PROCEDURE p2() +SET @foo = 10; +ERROR HY000: Cannot load from mysql.proc. The table is probably corrupted +# Procedure loaded from the cache +CALL p1(); +SHOW PROCEDURE STATUS; +ERROR HY000: Cannot load from mysql.proc. The table is probably corrupted +DROP TABLE mysql.proc; +RENAME TABLE proc_backup TO mysql.proc; +FLUSH TABLE mysql.proc; -- cgit v1.2.1 From 84c5abbd33856ba730b1e9091146d986f1923bfa Mon Sep 17 00:00:00 2001 From: Jim Winstead Date: Mon, 23 Nov 2009 14:38:08 -0800 Subject: Backport fix for Bug #27884. --- mysql-test/r/mysql.result | 1 + 1 file changed, 1 insertion(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/mysql.result b/mysql-test/r/mysql.result index 4affd884753..1945f893f04 100644 --- a/mysql-test/r/mysql.result +++ b/mysql-test/r/mysql.result @@ -199,4 +199,5 @@ COUNT (*) COUNT (*) 1 ERROR 2005 (HY000) at line 1: Unknown MySQL server host 'invalid_hostname' (errno) +
<
< & >
End of 5.0 tests -- cgit v1.2.1 From 82b115ec1619b7cf6dc1f308d875e154530b16a3 Mon Sep 17 00:00:00 2001 From: Satya B Date: Wed, 25 Nov 2009 12:25:49 +0530 Subject: Fix for BUG#47671 - wrong character-set after upgrade from 5.1.34 to 5.1.39 mysql client displays wrong character-set of server. When a user changes the charset of a server, mysql client 'status' command displays wrong charset but the command "SHOW VARIABLES LIKE "%charset%" displayed correct charset results. The problem is only with the mysql client's 'status' command output. In mysql client, the method mysql_store_lazy_result() returns 0 for success and non-zero for failure. The method com_status() was using this method wrongly. Fixed all such instances according to return value of the method mysql_store_lazy_result(). client/mysql.cc: Fix for BUG#47671 - wrong character-set after upgrade from 5.1.34 to 5.1.39 Fix com_status() method to use mysql_store_lazy_result() properly. mysql-test/r/bug47671.result: Fix for BUG#47671 - wrong character-set after upgrade from 5.1.34 to 5.1.39 Testcase for BUG#47671 mysql-test/t/bug47671-master.opt: Fix for BUG#47671 - wrong character-set after upgrade from 5.1.34 to 5.1.39 Testcase for BUG#47671 mysql-test/t/bug47671.test: Fix for BUG#47671 - wrong character-set after upgrade from 5.1.34 to 5.1.39 Testcase for BUG#47671 --- mysql-test/r/bug47671.result | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 mysql-test/r/bug47671.result (limited to 'mysql-test/r') diff --git a/mysql-test/r/bug47671.result b/mysql-test/r/bug47671.result new file mode 100644 index 00000000000..2cff6f1b59c --- /dev/null +++ b/mysql-test/r/bug47671.result @@ -0,0 +1,13 @@ +# +# Bug#47671 - wrong character-set after upgrade from 5.1.34 to 5.1.39 +# +# Extract only charset information from 'status' command output using regex +-------------- + +Server characterset: utf8 +Db characterset: utf8 +Client characterset: utf8 +Conn. characterset: utf8 + +-------------- + -- cgit v1.2.1 From 2bf2e8f9dd619ba7ecb635a0eb51a7a4f9db977b Mon Sep 17 00:00:00 2001 From: Satya B Date: Wed, 25 Nov 2009 15:08:52 +0530 Subject: Applying InnoDB snapshot 5.0-ss6230, Part 1. Fixes BUG#47777 BUG#47777 - innodb dies with spatial pk: Failing assertion: buf <= original_buf + buf_len Detailed revision comments: r6178 | jyang | 2009-11-17 08:52:11 +0200 (Tue, 17 Nov 2009) | 6 lines branches/5.0: Merge fix for bug #47777 from branches/5.1 -r6045 to bracnches/5.0. Treat the Geometry data same as Binary BLOB in ha_innobase::store_key_val_for_row(), since the Geometry data is stored as Binary BLOB in Innodb. --- mysql-test/r/innodb_bug47777.result | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 mysql-test/r/innodb_bug47777.result (limited to 'mysql-test/r') diff --git a/mysql-test/r/innodb_bug47777.result b/mysql-test/r/innodb_bug47777.result new file mode 100644 index 00000000000..fbba47edcfc --- /dev/null +++ b/mysql-test/r/innodb_bug47777.result @@ -0,0 +1,13 @@ +create table bug47777(c2 linestring not null, primary key (c2(1))) engine=innodb; +insert into bug47777 values (geomfromtext('linestring(1 2,3 4,5 6,7 8,9 10)')); +select count(*) from bug47777 where c2 =geomfromtext('linestring(1 2,3 4,5 6,7 8,9 10)'); +count(*) +1 +update bug47777 set c2=GeomFromText('POINT(1 1)'); +select count(*) from bug47777 where c2 =geomfromtext('linestring(1 2,3 4,5 6,7 8,9 10)'); +count(*) +0 +select count(*) from bug47777 where c2 = GeomFromText('POINT(1 1)'); +count(*) +1 +drop table bug47777; -- cgit v1.2.1 From 97d74332c2edd81754f3771f4212fa653f8c7864 Mon Sep 17 00:00:00 2001 From: Satya B Date: Wed, 25 Nov 2009 15:29:25 +0530 Subject: Applying InnoDB snapshot 5.0-ss6230, part 2. Fixes BUG#46000 BUG#46000 - using index called GEN_CLUST_INDEX crashes server Detailed revision comments: r6180 | jyang | 2009-11-17 10:54:57 +0200 (Tue, 17 Nov 2009) | 7 lines branches/5.0: Merge/Port fix for bug #46000 from branches/5.1 -r5895 to branches/5.0. Disallow creating index with the name of "GEN_CLUST_INDEX" which is reserved for the default system primary index. Minor adjusts on table name screening format for added tests. --- mysql-test/r/innodb_bug46000.result | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 mysql-test/r/innodb_bug46000.result (limited to 'mysql-test/r') diff --git a/mysql-test/r/innodb_bug46000.result b/mysql-test/r/innodb_bug46000.result new file mode 100644 index 00000000000..8a92fa973c0 --- /dev/null +++ b/mysql-test/r/innodb_bug46000.result @@ -0,0 +1,13 @@ +create table bug46000(`id` int,key `GEN_CLUST_INDEX`(`id`))engine=innodb; +ERROR HY000: Can't create table bug46000.frm' (errno: -1) +show warnings; +Level Code Message +Warning 1005 Cannot Create Index with name 'GEN_CLUST_INDEX'. The name is reserved for the system default primary index. +Error 1005 Can't create table bug46000.frm' (errno: -1) +create table bug46000(`id` int, key `GEN_clust_INDEX`(`id`))engine=innodb; +ERROR HY000: Can't create table bug46000.frm' (errno: -1) +create table bug46000(id int) engine=innodb; +create index GEN_CLUST_INDEX on bug46000(id); +ERROR HY000: Can't create table #sql-temporary' (errno: -1) +create index idx on bug46000(id); +drop table bug46000; -- cgit v1.2.1 From 14f2eb124448d69922c10fb818cbdf9b57f8ff63 Mon Sep 17 00:00:00 2001 From: Martin Hansson Date: Wed, 25 Nov 2009 11:02:25 +0100 Subject: Bug#48459: valgrind errors with query using 'Range checked for each record' There was an error in an internal structure in the range optimizer (SEL_ARG). Bad design causes parts of a data structure not to be initialized when it is in a certain state. All client code must check that this state is not present before trying to access the structure's data. Fixed by - Checking the state before trying to access data (in several places, most of which not covered by test case.) - Copying the keypart id when cloning SEL_ARGs mysql-test/r/range.result: Bug#48459: Test result. mysql-test/t/range.test: Bug#48459: Test case. sql/opt_range.cc: Bug#48459: Fix + doxygenated count_key_part_usage comment. --- mysql-test/r/range.result | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/range.result b/mysql-test/r/range.result index ab40eefdc82..64e00521cd2 100644 --- a/mysql-test/r/range.result +++ b/mysql-test/r/range.result @@ -1604,6 +1604,39 @@ str_to_date('', '%Y-%m-%d') 0000-00-00 DROP TABLE t1, t2; # +# Bug#48459: valgrind errors with query using 'Range checked for each +# record' +# +CREATE TABLE t1 ( +a INT, +b CHAR(2), +c INT, +d INT, +KEY ( c ), +KEY ( d, a, b ( 2 ) ), +KEY ( b ( 1 ) ) +); +INSERT INTO t1 VALUES ( NULL, 'a', 1, 2 ), ( NULL, 'a', 1, 2 ), +( 1, 'a', 1, 2 ), ( 1, 'a', 1, 2 ); +CREATE TABLE t2 ( +a INT, +c INT, +e INT, +KEY ( e ) +); +INSERT INTO t2 VALUES ( 1, 1, NULL ), ( 1, 1, NULL ); +# Should not give Valgrind warnings +SELECT 1 +FROM t1, t2 +WHERE t1.d <> '1' AND t1.b > '1' +AND t1.a = t2.a AND t1.c = t2.c; +1 +1 +1 +1 +1 +DROP TABLE t1, t2; +# # Bug #48665: sql-bench's insert test fails due to wrong result # CREATE TABLE t1 (a INT, b INT, PRIMARY KEY (a)); -- cgit v1.2.1 From 2ac344ecf662f6b5d901825850e3b5568ab91174 Mon Sep 17 00:00:00 2001 From: Georgi Kodinov Date: Fri, 27 Nov 2009 11:59:44 +0200 Subject: Bug #48872 : Privileges for stored functions ignored if function name is mixed case Transcode the procedure name to lowercase when searching for it in the hash. This is the missing part of the fix for bug #41049. --- mysql-test/r/sp-security.result | 61 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/sp-security.result b/mysql-test/r/sp-security.result index 106d08c8c12..17758218e35 100644 --- a/mysql-test/r/sp-security.result +++ b/mysql-test/r/sp-security.result @@ -519,4 +519,65 @@ DROP USER mysqltest_u1@localhost; DROP PROCEDURE p_suid; DROP FUNCTION f_suid; DROP TABLE t1; +# +# Bug #48872 : Privileges for stored functions ignored if function name +# is mixed case +# +CREATE DATABASE B48872; +USE B48872; +CREATE TABLE `TestTab` (id INT); +INSERT INTO `TestTab` VALUES (1),(2); +CREATE FUNCTION `f_Test`() RETURNS INT RETURN 123; +CREATE FUNCTION `f_Test_denied`() RETURNS INT RETURN 123; +CREATE USER 'tester'; +CREATE USER 'Tester'; +GRANT SELECT ON TABLE `TestTab` TO 'tester'; +GRANT EXECUTE ON FUNCTION `f_Test` TO 'tester'; +GRANT EXECUTE ON FUNCTION `f_Test_denied` TO 'Tester'; +SELECT f_Test(); +f_Test() +123 +SELECT * FROM TestTab; +id +1 +2 +SELECT * FROM TestTab; +id +1 +2 +SELECT `f_Test`(); +`f_Test`() +123 +SELECT `F_TEST`(); +`F_TEST`() +123 +SELECT f_Test(); +f_Test() +123 +SELECT F_TEST(); +F_TEST() +123 +SELECT * FROM TestTab; +ERROR 42000: SELECT command denied to user 'Tester'@'localhost' for table 'TestTab' +SELECT `f_Test`(); +ERROR 42000: execute command denied to user 'Tester'@'%' for routine 'B48872.f_Test' +SELECT `F_TEST`(); +ERROR 42000: execute command denied to user 'Tester'@'%' for routine 'B48872.f_Test' +SELECT f_Test(); +ERROR 42000: execute command denied to user 'Tester'@'%' for routine 'B48872.f_Test' +SELECT F_TEST(); +ERROR 42000: execute command denied to user 'Tester'@'%' for routine 'B48872.f_Test' +SELECT `f_Test_denied`(); +`f_Test_denied`() +123 +SELECT `F_TEST_DENIED`(); +`F_TEST_DENIED`() +123 +DROP TABLE `TestTab`; +DROP FUNCTION `f_Test`; +DROP FUNCTION `f_Test_denied`; +USE test; +DROP USER 'tester'; +DROP USER 'Tester'; +DROP DATABASE B48872; End of 5.0 tests. -- cgit v1.2.1 From b7ed14638fd36d68d2fbabb861e5467d6751cbab Mon Sep 17 00:00:00 2001 From: Georgi Kodinov Date: Fri, 27 Nov 2009 18:07:31 +0200 Subject: Addendum to bug #48872: disable output in the test case because errors are dependent on the case mode --- mysql-test/r/sp-security.result | 5 ----- 1 file changed, 5 deletions(-) (limited to 'mysql-test/r') diff --git a/mysql-test/r/sp-security.result b/mysql-test/r/sp-security.result index 17758218e35..1451f8e88fd 100644 --- a/mysql-test/r/sp-security.result +++ b/mysql-test/r/sp-security.result @@ -558,15 +558,10 @@ SELECT F_TEST(); F_TEST() 123 SELECT * FROM TestTab; -ERROR 42000: SELECT command denied to user 'Tester'@'localhost' for table 'TestTab' SELECT `f_Test`(); -ERROR 42000: execute command denied to user 'Tester'@'%' for routine 'B48872.f_Test' SELECT `F_TEST`(); -ERROR 42000: execute command denied to user 'Tester'@'%' for routine 'B48872.f_Test' SELECT f_Test(); -ERROR 42000: execute command denied to user 'Tester'@'%' for routine 'B48872.f_Test' SELECT F_TEST(); -ERROR 42000: execute command denied to user 'Tester'@'%' for routine 'B48872.f_Test' SELECT `f_Test_denied`(); `f_Test_denied`() 123 -- cgit v1.2.1 From 2faa75ed26bbd0644775907e9a959a17ad4e4ff6 Mon Sep 17 00:00:00 2001 From: Satya B Date: Mon, 30 Nov 2009 14:38:41 +0530 Subject: Applying InnoDB snapshot 5.1-ss6242, part 6. Fixes BUG#48482 1. BUG#48482 - innodb-autoinc.test fails with results difference 2. enable the disabled test Detailed revision comments: r6230 | sunny | 2009-11-24 23:52:43 +0200 (Tue, 24 Nov 2009) | 3 lines branches/5.1: Fix autoinc failing test results. (this should be skipped when merging 5.1 into zip) --- mysql-test/r/innodb-autoinc.result | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'mysql-test/r') diff --git a/mysql-test/r/innodb-autoinc.result b/mysql-test/r/innodb-autoinc.result index a40a13dbe9f..abb8f3da072 100644 --- a/mysql-test/r/innodb-autoinc.result +++ b/mysql-test/r/innodb-autoinc.result @@ -875,11 +875,11 @@ ALTER TABLE t1 CHANGE c1 d1 INT NOT NULL AUTO_INCREMENT; SELECT * FROM t1; d1 1 -3 +2 SELECT * FROM t1; d1 1 -3 +2 INSERT INTO t1 VALUES(null); Got one of the listed errors ALTER TABLE t1 AUTO_INCREMENT = 3; @@ -888,13 +888,13 @@ Table Create Table t1 CREATE TABLE `t1` ( `d1` int(11) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`d1`) -) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1 +) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=latin1 INSERT INTO t1 VALUES(null); SELECT * FROM t1; d1 1 +2 3 -4 DROP TABLE t1; SET @@SESSION.AUTO_INCREMENT_INCREMENT=1, @@SESSION.AUTO_INCREMENT_OFFSET=1; SHOW VARIABLES LIKE "%auto_inc%"; -- cgit v1.2.1 From 4b3114b60d10e4cedb0c98fe06f7e2ff023c3dbd Mon Sep 17 00:00:00 2001 From: Satya B Date: Mon, 30 Nov 2009 15:11:38 +0530 Subject: Applying InnoDB snapshot 5.1-ss6242, part 7. Fixes BUG#49032 1. BUG#49032 - auto_increment field does not initialize to last value in InnoDB Storage Engine 2. Fix whitespace issues and fix tests and make read float/double arg const Detailed revision comments: r6231 | sunny | 2009-11-25 10:26:27 +0200 (Wed, 25 Nov 2009) | 7 lines branches/5.1: Fix BUG#49032 - auto_increment field does not initialize to last value in InnoDB Storage Engine. We use the appropriate function to read the column value for non-integer autoinc column types, namely float and double. rb://208. Approved by Marko. r6232 | sunny | 2009-11-25 10:27:39 +0200 (Wed, 25 Nov 2009) | 2 lines branches/5.1: This is an interim fix, fix white space errors. r6233 | sunny | 2009-11-25 10:28:35 +0200 (Wed, 25 Nov 2009) | 2 lines branches/5.1: This is an interim fix, fix tests and make read float/double arg const. r6234 | sunny | 2009-11-25 10:29:03 +0200 (Wed, 25 Nov 2009) | 2 lines branches/5.1: This is an interim fix, fix whitepsace issues. --- mysql-test/r/innodb-autoinc.result | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/innodb-autoinc.result b/mysql-test/r/innodb-autoinc.result index abb8f3da072..ea759ec328c 100644 --- a/mysql-test/r/innodb-autoinc.result +++ b/mysql-test/r/innodb-autoinc.result @@ -1126,3 +1126,28 @@ SELECT * FROM T1; c1 c2 10 0 DROP TABLE T1; +DROP TABLE IF EXISTS T1; +Warnings: +Note 1051 Unknown table 'T1' +CREATE TABLE T1(C1 DOUBLE AUTO_INCREMENT KEY, C2 CHAR(10)) ENGINE=InnoDB; +INSERT INTO T1(C1, C2) VALUES (1, 'innodb'), (3, 'innodb'); +INSERT INTO T1(C2) VALUES ('innodb'); +SHOW CREATE TABLE T1; +Table Create Table +T1 CREATE TABLE `T1` ( + `C1` double NOT NULL AUTO_INCREMENT, + `C2` char(10) DEFAULT NULL, + PRIMARY KEY (`C1`) +) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1 +DROP TABLE T1; +CREATE TABLE T1(C1 FLOAT AUTO_INCREMENT KEY, C2 CHAR(10)) ENGINE=InnoDB; +INSERT INTO T1(C1, C2) VALUES (1, 'innodb'), (3, 'innodb'); +INSERT INTO T1(C2) VALUES ('innodb'); +SHOW CREATE TABLE T1; +Table Create Table +T1 CREATE TABLE `T1` ( + `C1` float NOT NULL AUTO_INCREMENT, + `C2` char(10) DEFAULT NULL, + PRIMARY KEY (`C1`) +) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1 +DROP TABLE T1; -- cgit v1.2.1 From cde05f0645cb3912bf7739c1bc8e0c8595b8a6b9 Mon Sep 17 00:00:00 2001 From: Satya B Date: Mon, 30 Nov 2009 15:16:45 +0530 Subject: Applying InnoDB snapshot 5.1-ss6242, part 8. Fixes BUG#47720 1. BUG#47720 - REPLACE INTO Autoincrement column with negative values. Detailed revision comments: r6235 | sunny | 2009-11-26 01:14:42 +0200 (Thu, 26 Nov 2009) | 9 lines branches/5.1: Fix Bug#47720 - REPLACE INTO Autoincrement column with negative values. This bug is similiar to the negative autoinc filter patch from earlier, with the additional handling of filtering out the negative column values set explicitly by the user. rb://184 Approved by Heikki. --- mysql-test/r/innodb-autoinc.result | 39 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/innodb-autoinc.result b/mysql-test/r/innodb-autoinc.result index ea759ec328c..2e0d2c1d776 100644 --- a/mysql-test/r/innodb-autoinc.result +++ b/mysql-test/r/innodb-autoinc.result @@ -1151,3 +1151,42 @@ T1 CREATE TABLE `T1` ( PRIMARY KEY (`C1`) ) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1 DROP TABLE T1; +DROP TABLE IF EXISTS t1; +Warnings: +Note 1051 Unknown table 't1' +CREATE TABLE t1 (c1 INT AUTO_INCREMENT PRIMARY KEY) ENGINE=InnoDB; +INSERT INTO t1 SET c1 = 1; +SHOW CREATE TABLE t1; +Table Create Table +t1 CREATE TABLE `t1` ( + `c1` int(11) NOT NULL AUTO_INCREMENT, + PRIMARY KEY (`c1`) +) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1 +INSERT INTO t1 SET c1 = 2; +INSERT INTO t1 SET c1 = -1; +SELECT * FROM t1; +c1 +-1 +1 +2 +INSERT INTO t1 SET c1 = -1; +Got one of the listed errors +SHOW CREATE TABLE t1; +Table Create Table +t1 CREATE TABLE `t1` ( + `c1` int(11) NOT NULL AUTO_INCREMENT, + PRIMARY KEY (`c1`) +) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=latin1 +REPLACE INTO t1 VALUES (-1); +SELECT * FROM t1; +c1 +-1 +1 +2 +SHOW CREATE TABLE t1; +Table Create Table +t1 CREATE TABLE `t1` ( + `c1` int(11) NOT NULL AUTO_INCREMENT, + PRIMARY KEY (`c1`) +) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=latin1 +DROP TABLE t1; -- cgit v1.2.1 From 732e5a263444178370ab0b4c6410e138d09218e7 Mon Sep 17 00:00:00 2001 From: Magne Mahre Date: Mon, 30 Nov 2009 12:30:28 +0100 Subject: Bug #20837 Apparent change of isolation level during transaction SET TRANSACTION ISOLATION LEVEL is used to temporarily set the trans.iso.level for the next transaction. After the transaction, the iso.level is (re-)set to value of the session variable 'tx_isolation'. The bug is caused by setting the thd->variables.tx_isolation field to the value of the session variable upon each statement commit. It should only be set at the end of the full transaction. The fix has been to remove the setting of the variable in ha_autocommit_or_rollback if we're in a transaction, as it will be correctly set in either ha_rollback or ha_commit_one_phase. If, on the other hand, we're in autocommit mode, tx_isolation will be explicitly set here. mysql-test/t/innodb_mysql.test: "SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED" sets the trans.isolation for the next transaction. We test that @@tx_isolation keeps this value during the transaction, and is only reset back to the session value at the end of the transaction. --- mysql-test/r/innodb_mysql.result | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) (limited to 'mysql-test/r') diff --git a/mysql-test/r/innodb_mysql.result b/mysql-test/r/innodb_mysql.result index 402ab3c1b16..2d93cbb47b3 100644 --- a/mysql-test/r/innodb_mysql.result +++ b/mysql-test/r/innodb_mysql.result @@ -2273,4 +2273,35 @@ END| DROP PROCEDURE p1; DROP VIEW v1; DROP TABLE t1,t2; +# +# Bug #20837 Apparent change of isolation +# level during transaction +# +SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; +CREATE TABLE t1 (s1 INT) ENGINE=InnoDB; +INSERT INTO t1 VALUES (1),(2); +COMMIT; +SET @@autocommit = 0; +COMMIT; +SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; +START TRANSACTION; +SELECT * FROM t1; +s1 +1 +2 +Should be READ UNCOMMITTED +SELECT @@tx_isolation; +@@tx_isolation +READ-UNCOMMITTED +INSERT INTO t1 VALUES (-1); +Should be READ UNCOMMITTED +SELECT @@tx_isolation; +@@tx_isolation +READ-UNCOMMITTED +COMMIT; +Should now be REPEATABLE READ +SELECT @@tx_isolation; +@@tx_isolation +REPEATABLE-READ +DROP TABLE t1; End of 5.1 tests -- cgit v1.2.1 From 248a74eaa10738a0e71e1fe1b11d7c236fe0f521 Mon Sep 17 00:00:00 2001 From: Georgi Kodinov Date: Tue, 1 Dec 2009 11:19:51 +0200 Subject: Revert of the push of bug #20837 due to failing regression tests. --- mysql-test/r/innodb_mysql.result | 31 ------------------------------- 1 file changed, 31 deletions(-) (limited to 'mysql-test/r') diff --git a/mysql-test/r/innodb_mysql.result b/mysql-test/r/innodb_mysql.result index 2d93cbb47b3..402ab3c1b16 100644 --- a/mysql-test/r/innodb_mysql.result +++ b/mysql-test/r/innodb_mysql.result @@ -2273,35 +2273,4 @@ END| DROP PROCEDURE p1; DROP VIEW v1; DROP TABLE t1,t2; -# -# Bug #20837 Apparent change of isolation -# level during transaction -# -SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; -CREATE TABLE t1 (s1 INT) ENGINE=InnoDB; -INSERT INTO t1 VALUES (1),(2); -COMMIT; -SET @@autocommit = 0; -COMMIT; -SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; -START TRANSACTION; -SELECT * FROM t1; -s1 -1 -2 -Should be READ UNCOMMITTED -SELECT @@tx_isolation; -@@tx_isolation -READ-UNCOMMITTED -INSERT INTO t1 VALUES (-1); -Should be READ UNCOMMITTED -SELECT @@tx_isolation; -@@tx_isolation -READ-UNCOMMITTED -COMMIT; -Should now be REPEATABLE READ -SELECT @@tx_isolation; -@@tx_isolation -REPEATABLE-READ -DROP TABLE t1; End of 5.1 tests -- cgit v1.2.1 From 821ff8501ca6820a4acbe550ed511290dffeb2a6 Mon Sep 17 00:00:00 2001 From: Mats Kindahl Date: Wed, 16 Dec 2009 13:28:47 +0100 Subject: WL#5151: Conversion between different types when replicating Fixes to make mysqlbinlog work correctly and updates to rpl_ndb result files. sql/log_event.cc: The processing of the MYSQL_STRING_TYPE is now done in table_def::type(), so the support functions for mysqlbinlog are changed to work correctly. --- mysql-test/r/mysqlbinlog_row_innodb.result | 40 +++++++++++++++--------------- mysql-test/r/mysqlbinlog_row_myisam.result | 8 +++--- 2 files changed, 24 insertions(+), 24 deletions(-) (limited to 'mysql-test/r') diff --git a/mysql-test/r/mysqlbinlog_row_innodb.result b/mysql-test/r/mysqlbinlog_row_innodb.result index 86f0b67ebb3..f11cc3221ad 100644 --- a/mysql-test/r/mysqlbinlog_row_innodb.result +++ b/mysql-test/r/mysqlbinlog_row_innodb.result @@ -2365,7 +2365,7 @@ BEGIN #010909 4:46:40 server id 1 end_log_pos # Write_rows: table id # flags: STMT_END_F ### INSERT INTO test.t1 ### SET -### @1=b'00000000' /* BIT(8) meta=256 nullable=1 is_null=0 */ +### @1=b'0' /* BIT(1) meta=1 nullable=1 is_null=0 */ ### @2=b'0000000000000000000000000000000000000000000000000000000000000000' /* BIT(64) meta=2048 nullable=1 is_null=0 */ ### @3=-128 (128) /* TINYINT meta=0 nullable=1 is_null=0 */ ### @4=0 /* TINYINT meta=0 nullable=1 is_null=0 */ @@ -2458,7 +2458,7 @@ BEGIN #010909 4:46:40 server id 1 end_log_pos # Write_rows: table id # flags: STMT_END_F ### INSERT INTO test.t1 ### SET -### @1=b'00000001' /* BIT(8) meta=256 nullable=1 is_null=0 */ +### @1=b'1' /* BIT(1) meta=1 nullable=1 is_null=0 */ ### @2=b'1111111111111111111111111111111111111111111111111111111111111111' /* BIT(64) meta=2048 nullable=1 is_null=0 */ ### @3=127 /* TINYINT meta=0 nullable=1 is_null=0 */ ### @4=-1 (255) /* TINYINT meta=0 nullable=1 is_null=0 */ @@ -2553,7 +2553,7 @@ BEGIN #010909 4:46:40 server id 1 end_log_pos # Write_rows: table id # flags: STMT_END_F ### INSERT INTO test.t1 ### SET -### @1=NULL /* type=16 meta=256 nullable=1 is_null=1 */ +### @1=NULL /* type=16 meta=1 nullable=1 is_null=1 */ ### @2=NULL /* type=16 meta=2048 nullable=1 is_null=1 */ ### @3=NULL /* type=1 meta=0 nullable=1 is_null=1 */ ### @4=NULL /* type=1 meta=0 nullable=1 is_null=1 */ @@ -2580,7 +2580,7 @@ BEGIN ### @25=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @26=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @27=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ -### @28=NULL /* type=10 meta=0 nullable=1 is_null=1 */ +### @28=NULL /* type=14 meta=0 nullable=1 is_null=1 */ ### @29=NULL /* type=12 meta=0 nullable=1 is_null=1 */ ### @30=1000000000 /* TIMESTAMP meta=0 nullable=0 is_null=0 */ ### @31=NULL /* TIMESTAMP meta=0 nullable=1 is_null=1 */ @@ -2634,7 +2634,7 @@ BEGIN ### @79=3 /* INT meta=0 nullable=1 is_null=0 */ ### INSERT INTO test.t1 ### SET -### @1=b'00000001' /* BIT(8) meta=256 nullable=1 is_null=0 */ +### @1=b'1' /* BIT(1) meta=1 nullable=1 is_null=0 */ ### @2=b'1111111111111111111111111111111111111111111111111111111111111111' /* BIT(64) meta=2048 nullable=1 is_null=0 */ ### @3=127 /* TINYINT meta=0 nullable=1 is_null=0 */ ### @4=0 /* TINYINT meta=0 nullable=1 is_null=0 */ @@ -2727,7 +2727,7 @@ BEGIN #010909 4:46:40 server id 1 end_log_pos # Update_rows: table id # flags: STMT_END_F ### UPDATE test.t1 ### WHERE -### @1=b'00000000' /* BIT(8) meta=256 nullable=1 is_null=0 */ +### @1=b'0' /* BIT(1) meta=1 nullable=1 is_null=0 */ ### @2=b'0000000000000000000000000000000000000000000000000000000000000000' /* BIT(64) meta=2048 nullable=1 is_null=0 */ ### @3=-128 (128) /* TINYINT meta=0 nullable=1 is_null=0 */ ### @4=0 /* TINYINT meta=0 nullable=1 is_null=0 */ @@ -2807,7 +2807,7 @@ BEGIN ### @78=b'00000000' /* SET(1 bytes) meta=63489 nullable=1 is_null=0 */ ### @79=1 /* INT meta=0 nullable=1 is_null=0 */ ### SET -### @1=b'00000001' /* BIT(8) meta=256 nullable=1 is_null=0 */ +### @1=b'1' /* BIT(1) meta=1 nullable=1 is_null=0 */ ### @2=b'1111111111111111111111111111111111111111111111111111111111111111' /* BIT(64) meta=2048 nullable=1 is_null=0 */ ### @3=127 /* TINYINT meta=0 nullable=1 is_null=0 */ ### @4=-1 (255) /* TINYINT meta=0 nullable=1 is_null=0 */ @@ -2900,7 +2900,7 @@ BEGIN #010909 4:46:40 server id 1 end_log_pos # Update_rows: table id # flags: STMT_END_F ### UPDATE test.t1 ### WHERE -### @1=b'00000001' /* BIT(8) meta=256 nullable=1 is_null=0 */ +### @1=b'1' /* BIT(1) meta=1 nullable=1 is_null=0 */ ### @2=b'1111111111111111111111111111111111111111111111111111111111111111' /* BIT(64) meta=2048 nullable=1 is_null=0 */ ### @3=127 /* TINYINT meta=0 nullable=1 is_null=0 */ ### @4=-1 (255) /* TINYINT meta=0 nullable=1 is_null=0 */ @@ -2980,7 +2980,7 @@ BEGIN ### @78=b'00000111' /* SET(1 bytes) meta=63489 nullable=1 is_null=0 */ ### @79=2 /* INT meta=0 nullable=1 is_null=0 */ ### SET -### @1=b'00000000' /* BIT(8) meta=256 nullable=1 is_null=0 */ +### @1=b'0' /* BIT(1) meta=1 nullable=1 is_null=0 */ ### @2=b'0000000000000000000000000000000000000000000000000000000000000000' /* BIT(64) meta=2048 nullable=1 is_null=0 */ ### @3=-128 (128) /* TINYINT meta=0 nullable=1 is_null=0 */ ### @4=0 /* TINYINT meta=0 nullable=1 is_null=0 */ @@ -3073,7 +3073,7 @@ BEGIN #010909 4:46:40 server id 1 end_log_pos # Update_rows: table id # flags: STMT_END_F ### UPDATE test.t1 ### WHERE -### @1=NULL /* type=16 meta=256 nullable=1 is_null=1 */ +### @1=NULL /* type=16 meta=1 nullable=1 is_null=1 */ ### @2=NULL /* type=16 meta=2048 nullable=1 is_null=1 */ ### @3=NULL /* type=1 meta=0 nullable=1 is_null=1 */ ### @4=NULL /* type=1 meta=0 nullable=1 is_null=1 */ @@ -3100,7 +3100,7 @@ BEGIN ### @25=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @26=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @27=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ -### @28=NULL /* type=10 meta=0 nullable=1 is_null=1 */ +### @28=NULL /* type=14 meta=0 nullable=1 is_null=1 */ ### @29=NULL /* type=12 meta=0 nullable=1 is_null=1 */ ### @30=1000000000 /* TIMESTAMP meta=0 nullable=0 is_null=0 */ ### @31=NULL /* TIMESTAMP meta=0 nullable=1 is_null=1 */ @@ -3153,7 +3153,7 @@ BEGIN ### @78=NULL /* TIMESTAMP meta=63489 nullable=1 is_null=1 */ ### @79=3 /* INT meta=0 nullable=1 is_null=0 */ ### SET -### @1=b'00000001' /* BIT(8) meta=256 nullable=1 is_null=0 */ +### @1=b'1' /* BIT(1) meta=1 nullable=1 is_null=0 */ ### @2=b'1111111111111111111111111111111111111111111111111111111111111111' /* BIT(64) meta=2048 nullable=1 is_null=0 */ ### @3=127 /* TINYINT meta=0 nullable=1 is_null=0 */ ### @4=0 /* TINYINT meta=0 nullable=1 is_null=0 */ @@ -3246,7 +3246,7 @@ BEGIN #010909 4:46:40 server id 1 end_log_pos # Update_rows: table id # flags: STMT_END_F ### UPDATE test.t1 ### WHERE -### @1=b'00000001' /* BIT(8) meta=256 nullable=1 is_null=0 */ +### @1=b'1' /* BIT(1) meta=1 nullable=1 is_null=0 */ ### @2=b'1111111111111111111111111111111111111111111111111111111111111111' /* BIT(64) meta=2048 nullable=1 is_null=0 */ ### @3=127 /* TINYINT meta=0 nullable=1 is_null=0 */ ### @4=0 /* TINYINT meta=0 nullable=1 is_null=0 */ @@ -3326,7 +3326,7 @@ BEGIN ### @78=b'00000110' /* SET(1 bytes) meta=63489 nullable=1 is_null=0 */ ### @79=4 /* INT meta=0 nullable=1 is_null=0 */ ### SET -### @1=NULL /* type=16 meta=256 nullable=1 is_null=1 */ +### @1=NULL /* type=16 meta=1 nullable=1 is_null=1 */ ### @2=NULL /* type=16 meta=2048 nullable=1 is_null=1 */ ### @3=NULL /* type=1 meta=0 nullable=1 is_null=1 */ ### @4=NULL /* type=1 meta=0 nullable=1 is_null=1 */ @@ -3353,7 +3353,7 @@ BEGIN ### @25=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @26=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @27=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ -### @28=NULL /* type=10 meta=0 nullable=1 is_null=1 */ +### @28=NULL /* type=14 meta=0 nullable=1 is_null=1 */ ### @29=NULL /* type=12 meta=0 nullable=1 is_null=1 */ ### @30=1000000000 /* TIMESTAMP meta=0 nullable=0 is_null=0 */ ### @31=NULL /* TIMESTAMP meta=0 nullable=1 is_null=1 */ @@ -3419,7 +3419,7 @@ BEGIN #010909 4:46:40 server id 1 end_log_pos # Delete_rows: table id # flags: STMT_END_F ### DELETE FROM test.t1 ### WHERE -### @1=b'00000001' /* BIT(8) meta=256 nullable=1 is_null=0 */ +### @1=b'1' /* BIT(1) meta=1 nullable=1 is_null=0 */ ### @2=b'1111111111111111111111111111111111111111111111111111111111111111' /* BIT(64) meta=2048 nullable=1 is_null=0 */ ### @3=127 /* TINYINT meta=0 nullable=1 is_null=0 */ ### @4=-1 (255) /* TINYINT meta=0 nullable=1 is_null=0 */ @@ -3512,7 +3512,7 @@ BEGIN #010909 4:46:40 server id 1 end_log_pos # Delete_rows: table id # flags: STMT_END_F ### DELETE FROM test.t1 ### WHERE -### @1=b'00000000' /* BIT(8) meta=256 nullable=1 is_null=0 */ +### @1=b'0' /* BIT(1) meta=1 nullable=1 is_null=0 */ ### @2=b'0000000000000000000000000000000000000000000000000000000000000000' /* BIT(64) meta=2048 nullable=1 is_null=0 */ ### @3=-128 (128) /* TINYINT meta=0 nullable=1 is_null=0 */ ### @4=0 /* TINYINT meta=0 nullable=1 is_null=0 */ @@ -3605,7 +3605,7 @@ BEGIN #010909 4:46:40 server id 1 end_log_pos # Delete_rows: table id # flags: STMT_END_F ### DELETE FROM test.t1 ### WHERE -### @1=b'00000001' /* BIT(8) meta=256 nullable=1 is_null=0 */ +### @1=b'1' /* BIT(1) meta=1 nullable=1 is_null=0 */ ### @2=b'1111111111111111111111111111111111111111111111111111111111111111' /* BIT(64) meta=2048 nullable=1 is_null=0 */ ### @3=127 /* TINYINT meta=0 nullable=1 is_null=0 */ ### @4=0 /* TINYINT meta=0 nullable=1 is_null=0 */ @@ -3698,7 +3698,7 @@ BEGIN #010909 4:46:40 server id 1 end_log_pos # Delete_rows: table id # flags: STMT_END_F ### DELETE FROM test.t1 ### WHERE -### @1=NULL /* type=16 meta=256 nullable=1 is_null=1 */ +### @1=NULL /* type=16 meta=1 nullable=1 is_null=1 */ ### @2=NULL /* type=16 meta=2048 nullable=1 is_null=1 */ ### @3=NULL /* type=1 meta=0 nullable=1 is_null=1 */ ### @4=NULL /* type=1 meta=0 nullable=1 is_null=1 */ @@ -3725,7 +3725,7 @@ BEGIN ### @25=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @26=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @27=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ -### @28=NULL /* type=10 meta=0 nullable=1 is_null=1 */ +### @28=NULL /* type=14 meta=0 nullable=1 is_null=1 */ ### @29=NULL /* type=12 meta=0 nullable=1 is_null=1 */ ### @30=1000000000 /* TIMESTAMP meta=0 nullable=0 is_null=0 */ ### @31=NULL /* TIMESTAMP meta=0 nullable=1 is_null=1 */ diff --git a/mysql-test/r/mysqlbinlog_row_myisam.result b/mysql-test/r/mysqlbinlog_row_myisam.result index b9366d941f8..4d1050af916 100644 --- a/mysql-test/r/mysqlbinlog_row_myisam.result +++ b/mysql-test/r/mysqlbinlog_row_myisam.result @@ -2584,7 +2584,7 @@ BEGIN ### @25=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @26=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @27=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ -### @28=NULL /* type=10 meta=0 nullable=1 is_null=1 */ +### @28=NULL /* type=14 meta=0 nullable=1 is_null=1 */ ### @29=NULL /* type=12 meta=0 nullable=1 is_null=1 */ ### @30=1000000000 /* TIMESTAMP meta=0 nullable=0 is_null=0 */ ### @31=NULL /* TIMESTAMP meta=0 nullable=1 is_null=1 */ @@ -3110,7 +3110,7 @@ BEGIN ### @25=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @26=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @27=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ -### @28=NULL /* type=10 meta=0 nullable=1 is_null=1 */ +### @28=NULL /* type=14 meta=0 nullable=1 is_null=1 */ ### @29=NULL /* type=12 meta=0 nullable=1 is_null=1 */ ### @30=1000000000 /* TIMESTAMP meta=0 nullable=0 is_null=0 */ ### @31=NULL /* TIMESTAMP meta=0 nullable=1 is_null=1 */ @@ -3365,7 +3365,7 @@ BEGIN ### @25=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @26=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @27=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ -### @28=NULL /* type=10 meta=0 nullable=1 is_null=1 */ +### @28=NULL /* type=14 meta=0 nullable=1 is_null=1 */ ### @29=NULL /* type=12 meta=0 nullable=1 is_null=1 */ ### @30=1000000000 /* TIMESTAMP meta=0 nullable=0 is_null=0 */ ### @31=NULL /* TIMESTAMP meta=0 nullable=1 is_null=1 */ @@ -3745,7 +3745,7 @@ BEGIN ### @25=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @26=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ ### @27=NULL /* type=246 meta=2560 nullable=1 is_null=1 */ -### @28=NULL /* type=10 meta=0 nullable=1 is_null=1 */ +### @28=NULL /* type=14 meta=0 nullable=1 is_null=1 */ ### @29=NULL /* type=12 meta=0 nullable=1 is_null=1 */ ### @30=1000000000 /* TIMESTAMP meta=0 nullable=0 is_null=0 */ ### @31=NULL /* TIMESTAMP meta=0 nullable=1 is_null=1 */ -- cgit v1.2.1