From fcb83cbf15653bbed15936d8eafb4fc7de3e743b Mon Sep 17 00:00:00 2001 From: Sergey Glukhov Date: Tue, 14 Dec 2010 12:33:03 +0300 Subject: Fixed following problems: --Bug#52157 various crashes and assertions with multi-table update, stored function --Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb --Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846 --Bug#57352 valgrind warnings when creating view --Recently discovered problem when a nested materialized derived table is used before being populated and it leads to incorrect result We have several modes when we should disable subquery evaluation. The reasons for disabling are different. It could be uselessness of the evaluation as in case of 'CREATE VIEW' or 'PREPARE stmt', or we should disable subquery evaluation if tables are not locked yet as it happens in bug#54475, or too early evaluation of subqueries can lead to wrong result as it happened in Bug#19077. Main problem is that if subquery items are treated as const they are evaluated in ::fix_fields(), ::fix_length_and_dec() of the parental items as a lot of these methods have Item::val_...() calls inside. We have to make subqueries non-const to prevent unnecessary subquery evaluation. At the moment we have different methods for this. Here is a list of these modes: 1. PREPARE stmt; We use UNCACHEABLE_PREPARE flag. It is set during parsing in sql_parse.cc, mysql_new_select() for each SELECT_LEX object and cleared at the end of PREPARE in sql_prepare.cc, init_stmt_after_parse(). If this flag is set subquery becomes non-const and evaluation does not happen. 2. CREATE|ALTER VIEW, SHOW CREATE VIEW, I_S tables which process FRM files We use LEX::view_prepare_mode field. We set it before view preparation and check this flag in ::fix_fields(), ::fix_length_and_dec(). Some bugs are fixed using this approach, some are not(Bug#57352, Bug#57703). The problem here is that we have a lot of ::fix_fields(), ::fix_length_and_dec() where we use Item::val_...() calls for const items. 3. Derived tables with subquery = wrong result(Bug19077) The reason of this bug is too early subquery evaluation. It was fixed by adding Item::with_subselect field The check of this field in appropriate places prevents const item evaluation if the item have subquery. The fix for Bug19077 fixes only the problem with convert_constant_item() function and does not cover other places(::fix_fields(), ::fix_length_and_dec() again) where subqueries could be evaluated. Example: CREATE TABLE t1 (i INT, j BIGINT); INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2); SELECT * FROM (SELECT MIN(i) FROM t1 WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3; DROP TABLE t1; 4. Derived tables with subquery where subquery is evaluated before table locking(Bug#54475, Bug#52157) Suggested solution is following: -Introduce new field LEX::context_analysis_only with the following possible flags: #define CONTEXT_ANALYSIS_ONLY_PREPARE 1 #define CONTEXT_ANALYSIS_ONLY_VIEW 2 #define CONTEXT_ANALYSIS_ONLY_DERIVED 4 -Set/clean these flags when we perform context analysis operation -Item_subselect::const_item() returns result depending on LEX::context_analysis_only. If context_analysis_only is set then we return FALSE that means that subquery is non-const. As all subquery types are wrapped by Item_subselect it allow as to make subquery non-const when it's necessary. mysql-test/r/derived.result: test case mysql-test/r/multi_update.result: test case mysql-test/r/view.result: test case mysql-test/suite/innodb/r/innodb_multi_update.result: test case mysql-test/suite/innodb/t/innodb_multi_update.test: test case mysql-test/suite/innodb_plugin/r/innodb_multi_update.result: test case mysql-test/suite/innodb_plugin/t/innodb_multi_update.test: test case mysql-test/t/derived.test: test case mysql-test/t/multi_update.test: test case mysql-test/t/view.test: test case sql/item.cc: --removed unnecessary code sql/item_cmpfunc.cc: --removed unnecessary checks --THD::is_context_analysis_only() is replaced with LEX::is_ps_or_view_context_analysis() sql/item_func.cc: --refactored context analysis checks sql/item_row.cc: --removed unnecessary checks sql/item_subselect.cc: --removed unnecessary code --added DBUG_ASSERT into Item_subselect::exec() which asserts that subquery execution can not happen if LEX::context_analysis_only is set, i.e. at context analysis stage. --Item_subselect::const_item() Return FALSE if LEX::context_analysis_only is set. It prevents subquery evaluation in ::fix_fields & ::fix_length_and_dec at context analysis stage. sql/item_subselect.h: --removed unnecessary code sql/mysql_priv.h: --Added new set of flags. sql/sql_class.h: --removed unnecessary code sql/sql_derived.cc: --added LEX::context_analysis_only analysis intialization/cleanup sql/sql_lex.cc: --init LEX::context_analysis_only field sql/sql_lex.h: --New LEX::context_analysis_only field sql/sql_parse.cc: --removed unnecessary code sql/sql_prepare.cc: --removed unnecessary code --added LEX::context_analysis_only analysis intialization/cleanup sql/sql_select.cc: --refactored context analysis checks sql/sql_show.cc: --added LEX::context_analysis_only analysis intialization/cleanup sql/sql_view.cc: --added LEX::context_analysis_only analysis intialization/cleanup --- mysql-test/t/multi_update.test | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'mysql-test/t/multi_update.test') diff --git a/mysql-test/t/multi_update.test b/mysql-test/t/multi_update.test index 85d2ed19fda..5298701d790 100644 --- a/mysql-test/t/multi_update.test +++ b/mysql-test/t/multi_update.test @@ -673,4 +673,15 @@ SET t3.a = 0; DROP TABLE t1, t2, t3; SET SESSION sql_safe_updates = DEFAULT; +--echo # +--echo # Bug#52157 various crashes and assertions with multi-table update, stored function +--echo # + +CREATE FUNCTION f1 () RETURNS BLOB RETURN 1; +CREATE TABLE t1 (f1 DATE); +INSERT INTO t1 VALUES('2001-01-01'); +UPDATE (SELECT 1 FROM t1 WHERE f1 = (SELECT f1() FROM t1)) x, t1 SET f1 = 1; +DROP FUNCTION f1; +DROP TABLE t1; + --echo end of tests -- cgit v1.2.1 From d1d166875ac2eec18d15611d0d82ba49b6def288 Mon Sep 17 00:00:00 2001 From: Jorgen Loland Date: Mon, 21 Feb 2011 16:49:03 +0100 Subject: BUG#11762751: UPDATE STATEMENT THROWS AN ERROR, BUT STILL UPDATES THE TABLE ENTRIES (formerly 55385) BUG#11764529: MULTI UPDATE+INNODB REPORTS ER_KEY_NOT_FOUND IF A TABLE IS UPDATED TWICE (formerly 57373) If multiple-table update updates a row through two aliases and the first update physically moves the row, the second update will fail to locate the row. This results in different errors depending on storage engine: * MyISAM: Got error 134 from storage engine * InnoDB: Can't find record in 'tbl' None of these errors accurately describe the problem. Furthermore, since MyISAM is non-transactional, the update executed first will be performed while the second will not. In addition, for two equal multiple-table update statements, one could succeed and the other fail based on whether or not the record actually moved or not. This was inconsistent. Two update operations may physically move a row: 1) Update of a column in a clustered primary key 2) Update of a column used to calculate which partition the row belongs to BUG#11764529 is about case 1) above, BUG#11762751 was about case 2). The fix for these bugs is to return with an error if multiple-table update is about to: a) Update a table through multiple aliases, and b) Perform an update that may physically more the row in at least one of these aliases This avoids * partial updates as described for MyISAM above, * provides the same error message that describes the actual problem for all SEs * inconsistent behavior where a statement fails or succeeds based on e.g. the partitioning algorithm of the table. mysql-test/r/multi_update.result: Add test for bug#57373 mysql-test/r/multi_update_innodb.result: Add test for bug#57373 mysql-test/r/partition.result: Add test for bug#55385 mysql-test/t/multi_update.test: Add test for bug#57373 mysql-test/t/multi_update_innodb.test: Add test for bug#57373 mysql-test/t/partition.test: Add test for bug#55385 sql/handler.cc: Translate handler error HA_ERR_RECORD_DELETED to server error sql/share/errmsg-utf8.txt: New error message for multi-table update where the same table is updated multiple times. sql/sql_update.cc: Add function unsafe_key_update() --- mysql-test/t/multi_update.test | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'mysql-test/t/multi_update.test') diff --git a/mysql-test/t/multi_update.test b/mysql-test/t/multi_update.test index 0e2abe578ce..496d045075a 100644 --- a/mysql-test/t/multi_update.test +++ b/mysql-test/t/multi_update.test @@ -683,4 +683,24 @@ UPDATE (SELECT 1 FROM t1 WHERE f1 = (SELECT f1() FROM t1)) x, t1 SET f1 = 1; DROP FUNCTION f1; DROP TABLE t1; +--echo # +--echo # BUG#57373: Multi update+InnoDB reports ER_KEY_NOT_FOUND if a +--echo # table is updated twice +--echo # + +# Results differ between storage engines. +# See multi_update_innodb.test for the InnoDB variant of this test +CREATE TABLE t1( + pk INT, + a INT, + PRIMARY KEY (pk) +) ENGINE=MyISAM; + +INSERT INTO t1 VALUES (0,0); +UPDATE t1 AS A, t1 AS B SET A.pk = 1, B.a = 2; +--echo +--echo # Should be (1,2) +SELECT * FROM t1; +DROP TABLE t1; + --echo end of tests -- cgit v1.2.1 From 5a0e7394a5ae0c7b6a1ea35b7ea3a8985325987a Mon Sep 17 00:00:00 2001 From: Jorgen Loland Date: Thu, 16 Jun 2011 08:24:00 +0200 Subject: BUG#11882110: UPDATE REPORTS ER_KEY_NOT_FOUND IF TABLE IS UPDATED TWICE For multi update it is not allowed to update a column of a table if that table is accessed through multiple aliases and either 1) the updated column is used as partitioning key 2) the updated column is part of the primary key and the primary key is clustered This check is done in unsafe_key_update(). The bug was that for case 2), it was checked whether updated_column_number == table_share->primary_key However, the primary_key variable is the index number of the primary key, not a column number. Prior to this bugfix, the first column was wrongly believed to be the primary key. The columns covered by an index is found in table->key_info[idx_number]->key_part. The bugfix is to check if any of the columns in the keyparts of the primary key are updated. The user-visible effect is that for storage engines with clustered primary key (e.g. InnoDB but not MyISAM) queries like "UPDATE t1 AS A JOIN t2 AS B SET A.primkey=..." will now error with "ERROR HY000: Primary key/partition key update is not allowed since the table is updated both as 'A' and 'B'." instead of "ERROR 1032 (HY000): Can't find record in 't1_tb'" even if primkey is not the first column in the table. This was the intended behavior of bugfix 11764529. mysql-test/r/multi_update.result: Add test for bug#11882110 mysql-test/r/multi_update_innodb.result: Add test for bug#11882110 mysql-test/t/multi_update.test: Add test for bug#11882110 mysql-test/t/multi_update_innodb.test: Add test for bug#11882110 sql/sql_update.cc: unsafe_key_update() wrongly checked if the primary key index number was the same as updated column number. Now it is checked whether any of the columns making up the primary key is updated. sql/table.h: Fix comment on TABLE_SHARE::primary_key. Incorrect comment was introduced by an earlier merge conflict (as per dlenev) --- mysql-test/t/multi_update.test | 48 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 47 insertions(+), 1 deletion(-) (limited to 'mysql-test/t/multi_update.test') diff --git a/mysql-test/t/multi_update.test b/mysql-test/t/multi_update.test index 496d045075a..4de574fbb0d 100644 --- a/mysql-test/t/multi_update.test +++ b/mysql-test/t/multi_update.test @@ -703,4 +703,50 @@ UPDATE t1 AS A, t1 AS B SET A.pk = 1, B.a = 2; SELECT * FROM t1; DROP TABLE t1; ---echo end of tests +--echo # +--echo # BUG#11882110: UPDATE REPORTS ER_KEY_NOT_FOUND IF TABLE IS +--echo # UPDATED TWICE +--echo # + +# Results differ between storage engines. This test is to verify that +# the bugfix did NOT change behavior for MyISAM. +# See multi_update_innodb.test for the InnoDB variant of this test +CREATE TABLE t1 ( + col_int_key int, + pk int, + col_int int, + key(col_int_key), + primary key (pk) +) ENGINE=MyISAM; +INSERT INTO t1 VALUES (1,2,3); + +--echo +CREATE TABLE t2 ( + col_int_key int, + pk_1 int, + pk_2 int, + col_int int, + key(col_int_key), + primary key (pk_1,pk_2) +) ENGINE=MyISAM; +INSERT INTO t2 VALUES (1,2,3,4); + +--echo +UPDATE t1 AS A NATURAL JOIN t1 B SET A.pk=5,B.pk=7; + +--echo +SELECT * FROM t1; + +--echo +UPDATE t2 AS A NATURAL JOIN t2 B SET A.pk_1=5,B.pk_1=7; +--echo +UPDATE t2 AS A NATURAL JOIN t2 B SET A.pk_2=10,B.pk_2=11; + +--echo +SELECT * FROM t2; + +DROP TABLE t1,t2; + + + + -- cgit v1.2.1