mariadb

Commit Graph

Author	SHA1	Message	Date
Michael Widenius	82a0b8ae30	strict.test now works.	13 years ago
Michael Widenius	5f1f2fc0e4	Applied all changes from Igor and Sanja	13 years ago
Alexander Barkov	e013bf9f0e	The bug MDEV-4489 "Replication of big5, cp932, gbk, sjis strings makes wrong values on slave" has been fixed. Problem: String constants of some Asian charsets (big5,cp932,gbk,sjis) can have backslash '\' (0x5C) in the second byte of multi-byte characters. Replicating of such constants using the standard '\'-escaping is dangerous. Therefore, constants of these charsets are replicated using hex notation: INSERT INTO t1 (a) VALUES (0x815C); However, 0xHHHH constants do not work well in some cases, because they can behave as strings and as numbers, depending on context (for example, depending on the data type of the column in an INSERT statement). This SQL script was not replicated correctly with statement-based replication: SET NAMES gbk; PREPARE STMT FROM 'INSERT INTO t1 (a) VALUES (?)'; SET @a = '1'; EXECUTE STMT USING @a; The INSERT statement was replicated as: INSERT INTO t1 (a) VALUES (0x31); '1' was correctly converted to the number 1 on master. But the 0x31 constant was treated as number 49 on slave. Fix: 1. Binary log now uses X'HHHH' instead of 0xHHHH constants. 2. The X'HHHH' constants now work always as strings, in all contexts. This is the SQL standard compliant behaviour. After the fix, the above statement is replicated as: INSERT INTO t1 (a) VALUES (X'31'); X'31' is treated as string '1' on slave, and is correctly converted to 1. modified: @ mysql-test/r/ctype_cp932_binlog_stm.result @ mysql-test/r/select.result @ mysql-test/r/select_jcl6.result @ mysql-test/r/select_pkeycache.result @ mysql-test/r/user_var-binlog.result @ mysql-test/r/varbinary.result @ mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.result @ mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result @ mysql-test/suite/rpl/r/rpl_charset_sjis.result @ mysql-test/suite/rpl/r/rpl_mdev382.result @ mysql-test/suite/rpl/t/rpl_charset_sjis.test @ mysql-test/t/ctype_cp932_binlog_stm.test @ mysql-test/t/select.test @ mysql-test/t/varbinary.test Adding and updating tests @ sql/item.cc @ sql/item.h @ sql/sql_yacc.yy @ sql/sql_lex.cc Splitting the implementations of X'HH' and 0xHH constants into two separate classes. Fixing the parser to distinguish the two syntaxes. @ sql/log_event.cc Using X'HH' instead of 0xHH for binary logging for string constants of the "dangerous" charsets. @ sql/sql_string.h Adding a helped method String::append_hex().	13 years ago
Sergei Golubchik	07315d3603	strmake_buf(X,Y) helper, equivalent to strmake(X,Y,sizeof(X)-1) with a bit of lame protection against abuse.	13 years ago
Alexey Botchkov	1a600125ff	MDEV-3917 multiple use locks (GET_LOCK) in one connection. The patch contributed by Konstantin Osipov applied. Native comments: Implement multiple user-level locks per connection. GET_LOCK() function in MySQL allows a connection to hold at most one user level lock. Taking a new lock automatically releases the old lock, if any. The limit of one lock per session existed since early versions of MySQL didn't have a deadlock detector for SQL locks. MDL patches in MySQL 5.5 added a deadlock detector, so starting from 5.5 it became possible to take multiple locks in any order -- a deadlock, should it occur, would be detected and an error returned to the client which closed the wait chain. This is exactly what is done in this patch: ULLs are moved to use MDL subsystem.	13 years ago
Sergei Golubchik	4ec6fe10e5	remove ULL() and LL(), because they're totally unnecessary and sometimes harmful (used with expressions)	13 years ago
Vladislav Vaintroub	fa01b76be7	MDEV-4243 : remove several clang warnings.	13 years ago
Nisha Gopalakrishnan	e85c90b9d5	BUG#11753852: IF() VALUES ARE EVALUATED DIFFERENTLY IN A REGULAR SQL VS PREPARED STATEMENT Analysis: --------- When passing user variables as parameters to the prepared statements, the IF() function evaluation turns out to be incorrect. Consider the example: SET @var1='0.038687'; SELECT @var1 , IF( @var1 = 0 , 1 ,@var1 ) AS sqlif ; +----------+----------+ \| @var1 \| sqlif \| +----------+----------+ \| 0.038687 \| 0.038687 \| +----------+----------+ Executing a prepared statement where the parameters are supplied: PREPARE fail_stmt FROM "SELECT ? , IF( ? = 0 , 1 , ? ) AS ps_if_fail" ; EXECUTE fail_stmt USING @var1 ,@var1 , @var1 ; +----------+------------+ \| ? \| ps_if_fail \| +----------+------------+ \| 0.038687 \| 1 \| +----------+------------+ 1 row in set (0.00 sec) In the regular statement or while executing the prepared statements without passing parameters, the decimal precision is set for the user variable of type string. The comparison function used for evaluation considered the precision while comparing the values. But while executing the prepared statement with the parameters supplied, the decimal precision was not set. Thus the comparison function chosen was different which looked at the absolute values for comparison. Fix: ---- The fix is to set 'decimals' field of Item_param to the default value which is nothing but the maximum number of decimals(NOT_FIXED_DEC). This is set for cases where the strings are converted to the numeric form within certain functions. Thus the value is not rounded off during comparison, ensuring correct evaluation.	13 years ago
Nisha Gopalakrishnan	0de3047952	BUG#11753852: IF() VALUES ARE EVALUATED DIFFERENTLY IN A REGULAR SQL VS PREPARED STATEMENT Analysis: --------- When passing user variables as parameters to the prepared statements, the IF() function evaluation turns out to be incorrect. Consider the example: SET @var1='0.038687'; SELECT @var1 , IF( @var1 = 0 , 1 ,@var1 ) AS sqlif ; +----------+----------+ \| @var1 \| sqlif \| +----------+----------+ \| 0.038687 \| 0.038687 \| +----------+----------+ Executing a prepared statement where the parameters are supplied: PREPARE fail_stmt FROM "SELECT ? , IF( ? = 0 , 1 , ? ) AS ps_if_fail" ; EXECUTE fail_stmt USING @var1 ,@var1 , @var1 ; +----------+------------+ \| ? \| ps_if_fail \| +----------+------------+ \| 0.038687 \| 1 \| +----------+------------+ 1 row in set (0.00 sec) In the regular statement or while executing the prepared statements without passing parameters, the decimal precision is set for the user variable of type string. The comparison function used for evaluation considered the precision while comparing the values. But while executing the prepared statement with the parameters supplied, the decimal precision was not set. Thus the comparison function chosen was different which looked at the absolute values for comparison. Fix: ---- The fix is to set 'decimals' field of Item_param to the default value which is nothing but the maximum number of decimals(NOT_FIXED_DEC). This is set for cases where the strings are converted to the numeric form within certain functions. Thus the value is not rounded off during comparison, ensuring correct evaluation.	13 years ago
Michael Widenius	068c61978e	Temporary commit of 10.0-merge	13 years ago
Sergei Golubchik	495fd27c0e	MDEV-4284 Assertion `cmp_items[(uint)cmp_type]' fails in sql/item_cmpfunc.cc Flip the switch and create Item_cache based on the argument's cmp_type, not argument's result_type(). Fix subselect_engine to calculate cmp_type correctly sql/item_subselect.h: mdev:4284	13 years ago
Sergei Golubchik	019f7425b7	MDEV-4281 Assertion `maybe_null && item->null_value' fails in make_sortkey on CASE with different return types, GROUP_CONCAT, GROUP BY Fix Item::get_date() to mark the item NULL when returning an error.	13 years ago
unknown	e3ac306157	[NOT] EXISTS to IN transformation.	13 years ago
Gleb Shchepa	19ea7c031d	Bug #11827369 : ASSERTION FAILED: !THD->LEX->CONTEXT_ANALYSIS_ONLY Some queries with the "SELECT ... FROM DUAL" nested subqueries failed with an assertion on debug builds. Non-debug builds were not affected. There were a few different issues with similar assertion failures on different queries: 1. The first problem was related to the incomplete propagation of the "non-constant" item status from underlying subquery items to the outer item tree: in some cases non-constants were interpreted as constants and evaluated at the preparation stage (val_int() calls withing fix_fields() etc). Thus, the default implementation of Item_ref::const_item() from the Item parent class didn't take into account the "const_item" status of the referenced item tree -- it used the insufficient "used_tables() == 0" check instead. This worked in most cases since our "non-constant" functions like RAND() and SLEEP() set the RAND_TABLE_BIT in the used table map, so they aren't non-constant from Item_ref's "point of view". However, the "SELECT ... FROM DUAL" subquery may have an empty map of used tables, but at the same time subqueries are never "constant" at the context analysis stage (preparation, view creation etc). So, the non-contantness of such subqueries was missed. Fix: the Item_ref::const_item() function has been overloaded to take into account both (ref)->const_item() status and tricky Item_ref::used_tables() return values, since the only (ref)->const_item() call is not enough there. 2. In some cases instead of the const_item() call we check a value of the Item::with_subselect field to recognize items with nested subqueries. However, the Item_ref class didn't propagate this value from the referenced item tree. Fix: Item::has_subquery() and Item_ref::has_subquery() functions have been backported from 5.6. All direct references to the with_subselect fields of nested items have been with the has_subquery() function call. 3. The Item_func_regex class didn't propagate with_subselect as well, since it overloads the Item_func::fix_fields() function with insufficient fix_fields() implementation. Fix: the Item_func_regex::fix_fields() function has been modified to gather "constant" statuses from inner items. 4. The Item_func_isnull::update_used_tables() function has a special branch for the underlying item where the maybe_null value is false: in this case it marks the Item_func_isnull as a "const_item" and sets the cached_value to false. However, the Item_func_isnull::val_int() was not in sync with update_used_tables(): it didn't take into account neither const_item_cache nor cached_value for the case of "args[0]->maybe_null == false optimization". As far as such an Item_func_isnull has "const_item() == true", it's ok to call Item_func_isnull::val_int() etc from outer items on preparation stage. In this case the server tried to call Item_func_isnull::args[0]->isnull(), and if the args[0] item contained a nested not-nullable subquery, it failed with an assertion. Fix: take the value of Item_func_isnull::const_item_cache into account in the val_int() function. 5. The auxiliary Item_is_not_null_test class has a similar optimization in the update_used_tables() function as the Item_func_isnull class has, and the same issue in the val_int() function. In addition to that the Item_is_not_null_test::update_used_tables() doesn't update the const_item_cache value, so the "maybe_null" optimization is useless there. Thus, we missed some optimizations of cases like these (before and after the fix): < <is_not_null_test>(a), --- > <cache>(<is_not_null_test>(a)), or < having (<is_not_null_test>(a) and <is_not_null_test>(a)) --- > having 1 etc. Fix: update Item_is_not_null_test::const_item_cache in update_used_tables() and take in into account in val_int().	13 years ago
Gleb Shchepa	e53345f04b	Bug #11827369 : ASSERTION FAILED: !THD->LEX->CONTEXT_ANALYSIS_ONLY Some queries with the "SELECT ... FROM DUAL" nested subqueries failed with an assertion on debug builds. Non-debug builds were not affected. There were a few different issues with similar assertion failures on different queries: 1. The first problem was related to the incomplete propagation of the "non-constant" item status from underlying subquery items to the outer item tree: in some cases non-constants were interpreted as constants and evaluated at the preparation stage (val_int() calls withing fix_fields() etc). Thus, the default implementation of Item_ref::const_item() from the Item parent class didn't take into account the "const_item" status of the referenced item tree -- it used the insufficient "used_tables() == 0" check instead. This worked in most cases since our "non-constant" functions like RAND() and SLEEP() set the RAND_TABLE_BIT in the used table map, so they aren't non-constant from Item_ref's "point of view". However, the "SELECT ... FROM DUAL" subquery may have an empty map of used tables, but at the same time subqueries are never "constant" at the context analysis stage (preparation, view creation etc). So, the non-contantness of such subqueries was missed. Fix: the Item_ref::const_item() function has been overloaded to take into account both (ref)->const_item() status and tricky Item_ref::used_tables() return values, since the only (ref)->const_item() call is not enough there. 2. In some cases instead of the const_item() call we check a value of the Item::with_subselect field to recognize items with nested subqueries. However, the Item_ref class didn't propagate this value from the referenced item tree. Fix: Item::has_subquery() and Item_ref::has_subquery() functions have been backported from 5.6. All direct references to the with_subselect fields of nested items have been with the has_subquery() function call. 3. The Item_func_regex class didn't propagate with_subselect as well, since it overloads the Item_func::fix_fields() function with insufficient fix_fields() implementation. Fix: the Item_func_regex::fix_fields() function has been modified to gather "constant" statuses from inner items. 4. The Item_func_isnull::update_used_tables() function has a special branch for the underlying item where the maybe_null value is false: in this case it marks the Item_func_isnull as a "const_item" and sets the cached_value to false. However, the Item_func_isnull::val_int() was not in sync with update_used_tables(): it didn't take into account neither const_item_cache nor cached_value for the case of "args[0]->maybe_null == false optimization". As far as such an Item_func_isnull has "const_item() == true", it's ok to call Item_func_isnull::val_int() etc from outer items on preparation stage. In this case the server tried to call Item_func_isnull::args[0]->isnull(), and if the args[0] item contained a nested not-nullable subquery, it failed with an assertion. Fix: take the value of Item_func_isnull::const_item_cache into account in the val_int() function. 5. The auxiliary Item_is_not_null_test class has a similar optimization in the update_used_tables() function as the Item_func_isnull class has, and the same issue in the val_int() function. In addition to that the Item_is_not_null_test::update_used_tables() doesn't update the const_item_cache value, so the "maybe_null" optimization is useless there. Thus, we missed some optimizations of cases like these (before and after the fix): < <is_not_null_test>(a), --- > <cache>(<is_not_null_test>(a)), or < having (<is_not_null_test>(a) and <is_not_null_test>(a)) --- > having 1 etc. Fix: update Item_is_not_null_test::const_item_cache in update_used_tables() and take in into account in val_int().	13 years ago
Michael Widenius	c65f9a1914	Don't reset maybe_null in update_used_tables(); This breaks ROLLUP This fixed failing test in group_by.test mysql-test/r/join_outer.result: Updated test case mysql-test/r/join_outer_jcl6.result: Updated test case sql/item.cc: Don't reset maybe_null in update_used_tables(); This breaks ROLLUP sql/item.h: Don't reset maybe_null in update_used_tables(); This breaks ROLLUP sql/item_cmpfunc.h: Don't reset maybe_null in update_used_tables(); This breaks ROLLUP	13 years ago
unknown	8a296e6ca2	backport of: Don't reset maybe_null in update_used_tables(); This breaks ROLLUP This fixed failing test in group_by.test	13 years ago
Sergei Golubchik	78d9fdb134	non-functional cleanup, clarifying CONVERT_IF_BIGGER_TO_BLOB	13 years ago
unknown	6f26aac940	MDEV-3873 & MDEV-3876 & MDEV-3912 : Wrong result (extra rows) with ALL subquery from a MERGE view. The problem was in the lost ability to be null for the table of a left join if it is a view/derived table. It hapenned because setup_table_map(), was called earlier then we merged the view or derived. Fixed by propagating new maybe_null flag during Item::update_used_tables(). Change in join_outer.test and join_outer_jcl6.test appeared because IS NULL reported no used tables (i.e. constant) for argument which could not be NULL and new maybe_null flag was propagated for IS NULL argument (Item_field) because table the Item_field belonged to changed its maybe_null status.	13 years ago
unknown	e99aa91e90	MDEV-3928: Assertion `example' failed in Item_cache::is_expensive_processor with a 2-level IN subquery Analysis: The following call stack shows that it is possible to set Item_cache::value_cached, and the relevant value without setting Item_cache::example. #0 Item_cache_temporal::store_packed at item.cc:8395 #1 get_datetime_value at item_cmpfunc.cc:915 #2 resolve_const_item at item.cc:7987 #3 propagate_cond_constants at sql_select.cc:12264 #4 propagate_cond_constants at sql_select.cc:12227 #5 optimize_cond at sql_select.cc:13026 #6 JOIN::optimize at sql_select.cc:1016 #7 st_select_lex::optimize_unflattened_subqueries at sql_lex.cc:3161 #8 JOIN::optimize_unflattened_subqueries at opt_subselect.cc:4880 #9 JOIN::optimize at sql_select.cc:1554 The fix is to set Item_cache_temporal::example even when the value is set directly by Item_cache_temporal::store_packed. This makes the Item_cache_temporal object consistent.	13 years ago
Sergei Golubchik	a058974440	remove HAVE_EXPLICIT_TEMPLATE_INSTANTIATION	13 years ago
Sergei Golubchik	4923d19b7c	small code cleanup taken from MySQL 5.6	13 years ago
unknown	8215ce4695	MDEV-3804: MySQL fix for bug#11765413 removed (we have better and more general fix for the problem). Test suite added.	13 years ago
unknown	b0d11675fb	Fix of MDEV-589. The problem was in incorrect detection of merged views in tem_direct_view_ref::used_tables() .	13 years ago
Sergei Golubchik	416d0aebbf	more fixes for test cases mysql-test/suite/innodb/include/restart_and_reinit.inc: drop and recreate mysql.innodb* tables when deleting innodb table spaces mysql-test/t/ssl_8k_key-master.opt: with loose- prefix ssl errors are ignored sql-common/client.c: compiler warnings sql/field.cc: use the new function sql/item.cc: don't convert time to double or decimal via longlong, this loses sub-second part. Use dedicated functions. sql/item.h: incorrect cast_to_int type for params sql/item_strfunc.cc: use the new function sql/lex.h: unused sql/my_decimal.h: helper macro sql/sql_plugin.cc: workaround for a compiler warning sql/sql_yacc.yy: unused sql/transaction.cc: fix the merge for SERVER_STATUS_IN_TRANS_READONLY protocol flag storage/sphinx/CMakeLists.txt: compiler warnings	13 years ago
unknown	54bb28d4a1	MDEV-486 LP BUG#1010116 fix. Link view/derived table fields to a real table to check turning the table record to null row. Item_direct_view_ref wrapper now checks if table is turned to null row.	13 years ago
Alexey Botchkov	589c62fefe	Bug #1043845 st_distance() results are incorrect depending on variable order. Autointersections of an object were treated as nodes, so the wrong result. per-file comments: mysql-test/r/gis.result Bug #1043845 st_distance() results are incorrect depending on variable order. test result updated. mysql-test/t/gis.test Bug #1043845 st_distance() results are incorrect depending on variable order. test case added. sql/item.cc small fix to make compilers happy. sql/item_geofunc.cc Bug #1043845 st_distance() results are incorrect depending on variable order. Skip intersection points when calculate distance.	13 years ago
Sergei Golubchik	51e14492e9	compilation warning	13 years ago
unknown	cdeabcfd43	MDEV-382: Incorrect quoting Various places in the server replication code was incorrectly quoting strings, which could lead to incorrect SQL on the slave/mysqlbinlog.	13 years ago
Sergey Glukhov	2f30b34095	Bug #14409015 MEMORY LEAK WHEN REFERENCING OUTER FIELD IN HAVING When resolving outer fields, Item_field::fix_outer_fields() creates new Item_refs for each execution of a prepared statement, so these must be allocated in the runtime memroot. The memroot switching before resolving JOIN::having causes these to be allocated in the statement root, leaking memory for each PS execution. sql/item_subselect.cc: addon, fix for 11829691, item could be created in runtime memroot, so we need to use real_item instead.	14 years ago
Sergey Glukhov	af3fdefca5	Bug #14409015 MEMORY LEAK WHEN REFERENCING OUTER FIELD IN HAVING When resolving outer fields, Item_field::fix_outer_fields() creates new Item_refs for each execution of a prepared statement, so these must be allocated in the runtime memroot. The memroot switching before resolving JOIN::having causes these to be allocated in the statement root, leaking memory for each PS execution.	14 years ago
Norvald H. Ryeng	cac1cd88ab	Bug#13003736 CRASH IN ITEM_REF::WALK WITH SUBQUERIES Problem: Some queries with subqueries and a HAVING clause that consists only of a column not in the select or grouping lists causes the server to crash. During parsing, an Item_ref is constructed for the HAVING column. The name of the column is resolved when JOIN::prepare calls fix_fields() on its having clause. Since the column is not mentioned in the select or grouping lists, a ref pointer is not found and a new Item_field is created instead. The Item_ref is replaced by the Item_field in the tree of HAVING clauses. Since the tree consists only of this item, the pointer that is updated is JOIN::having. However, st_select_lex::having still points to the Item_ref as the root of the tree of HAVING clauses. The bug is triggered when doing filesort for create_sort_index(). When find_all_keys() calls select->cond->walk() it eventually reaches Item_subselect::walk() where it continues to walk the having clauses from lex->having. This means that it finds the Item_ref instead of the new Item_field, and Item_ref::walk() tries to dereference the ref pointer, which is still null. The crash is reproducible only in 5.5, but the problem lies latent in 5.1 and trunk as well. Fix: After calling fix_fields on the having clause in JOIN::prepare(), set select_lex::having to point to the same item as JOIN::having. This patch also fixes a bug in 5.1 and 5.5 that is triggered if the query is executed as a prepared statement. The Item_field is created in the runtime arena when the query is prepared, and the pointer to the item is saved by st_select_lex::fix_prepare_information() and brought back as a dangling pointer when the query is executed, after the runtime arena has been reclaimed. Fix: Backport fix from trunk that switches to the permanent arena before calling Item_ref::fix_fields() in JOIN::prepare(). sql/item.cc: Set context when creating Item_field. sql/sql_select.cc: Switch to permanent arena and update select_lex->having.	14 years ago
Norvald H. Ryeng	5f61cc438b	Bug#13003736 CRASH IN ITEM_REF::WALK WITH SUBQUERIES Problem: Some queries with subqueries and a HAVING clause that consists only of a column not in the select or grouping lists causes the server to crash. During parsing, an Item_ref is constructed for the HAVING column. The name of the column is resolved when JOIN::prepare calls fix_fields() on its having clause. Since the column is not mentioned in the select or grouping lists, a ref pointer is not found and a new Item_field is created instead. The Item_ref is replaced by the Item_field in the tree of HAVING clauses. Since the tree consists only of this item, the pointer that is updated is JOIN::having. However, st_select_lex::having still points to the Item_ref as the root of the tree of HAVING clauses. The bug is triggered when doing filesort for create_sort_index(). When find_all_keys() calls select->cond->walk() it eventually reaches Item_subselect::walk() where it continues to walk the having clauses from lex->having. This means that it finds the Item_ref instead of the new Item_field, and Item_ref::walk() tries to dereference the ref pointer, which is still null. The crash is reproducible only in 5.5, but the problem lies latent in 5.1 and trunk as well. Fix: After calling fix_fields on the having clause in JOIN::prepare(), set select_lex::having to point to the same item as JOIN::having. This patch also fixes a bug in 5.1 and 5.5 that is triggered if the query is executed as a prepared statement. The Item_field is created in the runtime arena when the query is prepared, and the pointer to the item is saved by st_select_lex::fix_prepare_information() and brought back as a dangling pointer when the query is executed, after the runtime arena has been reclaimed. Fix: Backport fix from trunk that switches to the permanent arena before calling Item_ref::fix_fields() in JOIN::prepare().	14 years ago
Vladislav Vaintroub	afe1ef5e3a	LP1008334 : Speedup specific datetime queries that got slower with introduction of microseconds in 5.3 - Item::get_seconds() now skips decimal arithmetic, if decimals is 0. This significantly speeds up from_unixtime() if no fractional part is passed. - replace sprintfs used to format temporal values by hand-coded formatting Query1 (original query in the bug report) BENCHMARK(10000000,DATE_SUB(FROM_UNIXTIME(RAND() * 2147483648), INTERVAL (FLOOR(1 + RAND() * 365)) DAY)) Query2 (Variation of query1 that does not use fractional part in FROM_UNIXTIME parameter) BENCHMARK(10000000,DATE_SUB(FROM_UNIXTIME(FLOOR(RAND() * 2147483648)), INTERVAL (FLOOR(1 + RAND() * 365)) DAY)) Prior to the patch, the runtimes were (32 bit compilation/AMD machine) Query1: 41.53 sec Query2: 23.90 sec With the patch, the runtimes are Query1: 32.32 sec (speed up due to removing sprintf) Query2: 12.06 sec (speed up due to skipping decimal arithmetic)	14 years ago
Sergei Golubchik	beec2a2b1d	MDEV-241 lp:992722 - Server crashes in get_datetime_value Create an Item_cache based on item's cmp_type, not result_type in subselect_engine. Use result_field in Item_cache_temporal::cache_value(), just like all other Item_cache*::cache_value() do.	14 years ago
Igor Babaev	4ca9b8eb3a	Fixed bug #915222 . This bug happened because the function find_field_in_view formed autogenerated names of view columns without a possibility to roll them back. In some situation it could cause memory misuses reported by valgrind or even crashes.	14 years ago
Sergey Petrunya	91d17a9c20	BUG#952583: Server crashes in Item_field::fix_after_pullout on INSERT .. SELECT - Take into account that there may exist Item_field objects with context==NULL.	14 years ago
Tor Didriksen	13053fbe54	Bug#13721076 CRASH WITH TIME TYPE/TIMESTAMP() AND WARNINGS IN SUBQUERY The table contains one time value: '00:00:32' This value is converted to timestamp by a subquery. In convert_constant_item we call (item)->is_null() which triggers execution of the Item_singlerow_subselect subquery, and the string "0000-00-00 00:00:32" is cached by Item_cache_datetime. We continue execution and call update_null_value, which calls val_int() on the cached item, which converts the time value to ((longlong) 32) Then we continue to do (item)->save_in_field() which ends up in Item_cache_datetime::val_str() which fails, since (32 < 101) in number_to_datetime, and val_str() returns NULL. Item_singlerow_subselect::val_str isnt prepared for this: if exec() succeeds, and return !null_value, then val_str() must succeed. Solution: refuse to cache strings like "0000-00-00 00:00:32" in Item_cache_datetime::cache_value, and return NULL instead. This is similar to the solution for Bug#11766860 - 60085: CRASH IN ITEM::SAVE_IN_FIELD() WITH TIME DATA TYPE This patch is for 5.5 only. The issue is not present after WL#946, since a time value will be converted to a proper timestamp, with the current date rather than "0000-00-00" mysql-test/r/subselect.result: New test case. mysql-test/t/subselect.test: New test case. sql/item.cc: Verify proper date format before caching timestamps. sql/item_timefunc.cc: Use named constant for readability.	14 years ago
Tor Didriksen	c8f4e2793d	Bug#13721076 CRASH WITH TIME TYPE/TIMESTAMP() AND WARNINGS IN SUBQUERY The table contains one time value: '00:00:32' This value is converted to timestamp by a subquery. In convert_constant_item we call (item)->is_null() which triggers execution of the Item_singlerow_subselect subquery, and the string "0000-00-00 00:00:32" is cached by Item_cache_datetime. We continue execution and call update_null_value, which calls val_int() on the cached item, which converts the time value to ((longlong) 32) Then we continue to do (item)->save_in_field() which ends up in Item_cache_datetime::val_str() which fails, since (32 < 101) in number_to_datetime, and val_str() returns NULL. Item_singlerow_subselect::val_str isnt prepared for this: if exec() succeeds, and return !null_value, then val_str() must succeed. Solution: refuse to cache strings like "0000-00-00 00:00:32" in Item_cache_datetime::cache_value, and return NULL instead. This is similar to the solution for Bug#11766860 - 60085: CRASH IN ITEM::SAVE_IN_FIELD() WITH TIME DATA TYPE This patch is for 5.5 only. The issue is not present after WL#946, since a time value will be converted to a proper timestamp, with the current date rather than "0000-00-00"	14 years ago
Norvald H. Ryeng	ad031d5110	Bug#13031606 VALUES() IN A SELECT STATEMENT CRASHES SERVER Problem: Grouping results by VALUES(alias for string literal) causes the server to crash. Item_insert_values is not constructed to handle other types of arguments than field and reference to field. In this case, the argument is an Item_string, and this causes Item_insert_values::fix_fields() to crash. Fix: Issue an error message when the argument to Item_insert_values is not a field or a reference to a field. This is slightly in breach with documentation, which states that VALUES should return NULL, but the error message is only issued in cases where the server otherwise would crash, so there is no change in behavior for queries that already work. Future versions will restrict syntax so that using VALUES in this way is illegal. mysql-test/r/errors.result: Add test case for bug #13031606. mysql-test/t/errors.test: Add test case for bug #13031606. sql/item.cc: Issue error message if argument is not field or reference to field.	14 years ago
Norvald H. Ryeng	2e72df370b	Bug#13031606 VALUES() IN A SELECT STATEMENT CRASHES SERVER Problem: Grouping results by VALUES(alias for string literal) causes the server to crash. Item_insert_values is not constructed to handle other types of arguments than field and reference to field. In this case, the argument is an Item_string, and this causes Item_insert_values::fix_fields() to crash. Fix: Issue an error message when the argument to Item_insert_values is not a field or a reference to a field. This is slightly in breach with documentation, which states that VALUES should return NULL, but the error message is only issued in cases where the server otherwise would crash, so there is no change in behavior for queries that already work. Future versions will restrict syntax so that using VALUES in this way is illegal.	14 years ago
Praveenkumar Hulakund	c22c9270fb	Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION Analysis: ======================== sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input, instead of escape character in a string literal then sql_mode can be set to "NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary character like any other. SQL_MODE set applies to the current client session. And while creating the stored procedure, MySQL stores the current sql_mode and always executes the stored procedure in sql_mode stored with the Procedure, regardless of the server SQL mode in effect when the routine is invoked. In the scenario (for which bug is reported), the routine is created with sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode is "" (NOT SET) by executing statement "call testp('Axel\'s')". Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function) is considered as escape character and column "a" (of table "t1") values are updated with "Axel's". The binary log generated for above update operation is as below, set sql_mode=XXXXXX (for no_backslash_escapes) update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci'); While logging stored procedure statements, the local variables (params) used in statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) (http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const) On slave, these logs are applied. NAME_CONST is parsed to get the variable and its value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode is also logged in. So that at slave this sql_mode is set before executing the statements of routine. So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character and parsing reported error for "'" (as we have only one "'" no backslash). At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES". But above error reported while writing bin log, "'" (of Axel's) is escaped with "\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped while writing NAME_CONST for string variable(param, local variable) in bin log Airrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is that logging string parameter does not take into account sql_mode value. Fix: ======================== So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping characters as (n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to escape such characters while writing NAME_CONST for string variables in bin log. And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is represented as ''. http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several ways to include quote characters within a string: ) mysql-test/r/sql_mode.result: Added test case for Bug#12601974. mysql-test/suite/binlog/r/binlog_sql_mode.result: Appended result of test cases added for Bug#12601974. mysql-test/suite/binlog/t/binlog_sql_mode.test: Added test case for Bug#12601974. mysql-test/t/sql_mode.test: Appended result of test cases added for Bug#12601974.	14 years ago
Praveenkumar Hulakund	9af695fb45	Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION Analysis: ======================== sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input, instead of escape character in a string literal then sql_mode can be set to "NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary character like any other. SQL_MODE set applies to the current client session. And while creating the stored procedure, MySQL stores the current sql_mode and always executes the stored procedure in sql_mode stored with the Procedure, regardless of the server SQL mode in effect when the routine is invoked. In the scenario (for which bug is reported), the routine is created with sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode is "" (NOT SET) by executing statement "call testp('Axel\'s')". Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function) is considered as escape character and column "a" (of table "t1") values are updated with "Axel's". The binary log generated for above update operation is as below, set sql_mode=XXXXXX (for no_backslash_escapes) update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci'); While logging stored procedure statements, the local variables (params) used in statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) (http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const) On slave, these logs are applied. NAME_CONST is parsed to get the variable and its value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode is also logged in. So that at slave this sql_mode is set before executing the statements of routine. So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character and parsing reported error for "'" (as we have only one "'" no backslash). At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES". But above error reported while writing bin log, "'" (of Axel's) is escaped with "\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped while writing NAME_CONST for string variable(param, local variable) in bin log Airrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is that logging string parameter does not take into account sql_mode value. Fix: ======================== So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping characters as (n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to escape such characters while writing NAME_CONST for string variables in bin log. And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is represented as ''. http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several ways to include quote characters within a string: )	14 years ago
MySQL Build Team	7177a2b9d7	Updated/added copyright headers	14 years ago
MySQL Build Team	91a5be2cab	Updated/added copyright headers	14 years ago
unknown	79a04a2c9c	Moving LP BUG#794005 to 5.3 + fixing INSERT of multi-table view.	14 years ago
unknown	b4643d75fe	fix for LP BUG#921878. Problem was in try to check/use Item_direct_ref of derived view when we have to use real Item_field under it.	14 years ago
Guilhem Bichot	9e0b69c0b7	Fixes for: BUG#13519696 - 62940: SELECT RESULTS VARY WITH VERSION AND WITH/WITHOUT INDEX RANGE SCAN BUG#13453382 - REGRESSION SINCE 5.1.39, RANGE OPTIMIZER WRONG RESULTS WITH DECIMAL CONVERSION BUG#13463488 - 63437: CHAR & BETWEEN WITH INDEX RETURNS WRONG RESULT AFTER MYSQL 5.1. Those are all cases where the range optimizer got it wrong with > and >=. mysql-test/r/range.result: Without the code fix for DECIMAL, "select count(val) from t2 where val > 0.1155" (which uses a range scan) returned 127 instead of 128); Moreover, both select * from t1 force index (primary) where a=1 and c>= 2.9; and select * from t1 force index (primary) where a=1 and c> 2.9; would miss "1 1 3". Without the code fix for strings, both SELECT * FROM t1 WHERE F1 >= 'A '; and SELECT * FROM t1 WHERE F1 BETWEEN 'A ' AND 'AAAAA'; would miss "A A A". sql/item.cc: Preamble to the explanations below: opt_range.cc:get_mm_leaf() does this (this is not changed by the patch): changes column > value to column OP V where: * V is what is in "column" after we stored "value" in it (such store operation may have done rounding...) * OP is > or >=, depending on what's correct. For example, if c is an INT column, c > 2.9 is changed to c OP 3 where OP is >= ('>' would not be correct). The bugs below are cases where we chose OP wrongly. Note that such transformations are visible in the optimizer trace. 1) Fix for STRING. In the scenario with CHAR(5) in range.test, this happens, in get_mm_tree(), for the condition F1>='A ': * value->save_in_field_no_warnings(field, 1) wants to store the right argument (named 'item') into the CHAR(5) field; this stores 'A ' (the item's value) padded with spaces (which changes nothing: still 'A ') * we come to case Item_func::GE_FUNC: /* Don't use open ranges for partial key_segments / if ((!(key_part->flag & HA_PART_KEY_SEG)) && (stored_field_cmp_to_item(param->thd, field, value) < 0)) tree->min_flag= NEAR_MIN; tree->max_flag=NO_MAX_RANGE; What this wants to do is: if the field's value is strictly smaller than the item's, then ">=" can be changed to ">" (this is an optimization, it can help pruning one useless partition). stored_field_cmp_to_item() is called; it compares the field's and item's values: the item's value (Item_string::val_str()) is 'A ') and the field's value (Field_string::val_str()) is 'A' (yes val_str() removes end spaces unless sql_mode='PAD_CHAR_TO_FULL_LENGTH'); and the comparison is done with stringcmp() which considers end spaces as relevant; as end spaces differ, function returns a negative number, and ">='A '" becomes ">'A'" (i.e. the NEAR_MIN flag is turned on). During execution the index range scan code will search for "A", find a match, but exclude it (because of ">"), wrongly. The badness is the string comparison done by stored_field_cmp_to_item(): we use the reply of this function to determine where the index search should start, so it should do comparison like index search does comparisons; index search comparisons are ha_key_cmp() which uses a collation-aware comparison (in our case, my_strnncollsp_simple(), which ignores end spaces); so stored_field_cmp_to_item() needs to do the same. When this is fixed, condition becomes ">='A '". 2) Fix for DECIMAL: just like in other comparisons in stored_field_cmp_to_item(), we must first pass the field and then the item; otherwise expectations on what <0 and >0 mean (inferiority, superiority) get violated. In the test in range.test about c>2.9: c is an INT column, so 2.9 gets stored as 3, then stored_field_cmp_to_item() compares 3 and 2.9; because of the wrong order of arguments passed to my_decimal_cmp(), range optimizer thinks that 3 is < 2.9 and thus changes "c> 2.9" to "c> 3". After fixing the order, it changes to the correct "c>= 3". In the test in range.inc for val > 0.1155, it was changed to val > 0.116, now it is changed to val >= 0.116.	14 years ago
Guilhem Bichot	440d871bf9	Fixes for: BUG#13519696 - 62940: SELECT RESULTS VARY WITH VERSION AND WITH/WITHOUT INDEX RANGE SCAN BUG#13453382 - REGRESSION SINCE 5.1.39, RANGE OPTIMIZER WRONG RESULTS WITH DECIMAL CONVERSION BUG#13463488 - 63437: CHAR & BETWEEN WITH INDEX RETURNS WRONG RESULT AFTER MYSQL 5.1. Those are all cases where the range optimizer got it wrong with > and >=.	14 years ago
Tor Didriksen	c796415943	Bug#13463415 followup: compensate for compiler bug	14 years ago

... 3 4 5 6 7 ...

3513 Commits (d2f84ab978c596fcaa96e0d53282b57f6225e50f)