An error occurred fetching the project authors.
- 27 Feb, 2013 1 commit
-
-
Gleb Shchepa authored
IN IN-CLAUSE USING MYISAM OR MEMORY ENGINE Backport from 5.6. Original message: The coincidences caused a data loss: * The query has IN subqueries nested twice, * the WHERE clause of the inner subquery refers to the outer field, and the whole WHERE clause returns FALSE, * the inner subquery has a LEFT JOIN that joins a single row with a row of NULLs; one of that NULL columns represents the select list of the subquery. Normally, that inner subquery should return empty record set. However, in our case: * the Item_is_not_null_test item goes constant, since its underlying field is NULL (because of LEFT JOIN ... ON FALSE of const table row with a row of nulls); * we evaluate Item_is_not_null_test::val_int() as a part of fake HAVING expression of the transformed subquery; * as far as the underlying field is NULL, we optimize out the whole fake HAVING expression as FALSE as well as a whole subquery with a zero result: Impossible HAVING noticed after reading const tables"; * thus, the optimizer ignores the presence of the WHERE clause (the WHERE expression is FALSE in our case, so the subquery should return empty set); * however, during the evaluation of the Item_is_not_null_test::val_int() in the optimizer, it marked its "owner" with the "was_null" flag -- that forced the subquery to return UNKNOWN instead of empty set. That caused a wrong result. The problem is a regression of the small cleanup in the fix for the bug11827369 (the Item_is_not_null_test part) that conflicts with optimizations in the fix for the bug11752543. Before that regression the Item_is_not_null_test items never were constants. The fix is the rollback of Item_is_not_null_test parts of the bug11827369 fix.
-
- 23 Jan, 2013 1 commit
-
-
Gleb Shchepa authored
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().
-
- 21 Dec, 2012 1 commit
-
-
Roy Lyseng authored
The problem is a shift operation that is not 64-bit safe. The consequence is that used tables information for a join with 32 tables or more will be incorrect. Fixed by adding a type cast in Item_sum::update_used_tables(). Also used the opportunity to fix some other potential bugs by adding an explicit type-cast to an integer in a left-shift operation. Some of them were quite harmless, but was fixed in order to get the same signed-ness as the other operand of the operation it was used in. sql/item_cmpfunc.cc Adjusted signed-ness for some integers in left-shift. sql/item_subselect.cc Added type-cast to nesting_map (which is a 32/64 bit type, so potential bug for deeply nested queries). sql/item_sum.cc Added type-cast to nesting_map (32/64-bit type) and table_map (64-bit type). sql/opt_range.cc Added type-cast to ulonglong (which is a 64-bit type). sql/sql_base.cc Added type-cast to nesting_map (which is a 32/64-bit type). sql/sql_select.cc Added type-cast to nesting_map (32/64-bit type) and key_part_map (64-bit type). sql/strfunc.cc Changed type-cast from longlong to ulonglong, to preserve signed-ness.
-
- 25 Sep, 2012 1 commit
-
-
Tor Didriksen authored
Bug #11764313 57135: CRASH IN ITEM_FUNC_CASE::FIND_ITEM WITH CASE WHEN Bug #11764818 57692: Crash in item_func_in::val_int() with ZEROFILL
-
- 17 May, 2012 1 commit
-
-
Mayank Prasad authored
Issue/Cause: Issue is of memory corruption.During optimization phase, pattern to be matched in where clause, is prepared. This is done in Item_func_concat::val_str() function which forms the resultant string (tmp_value) and return its pointer. In caller, Item_func_like::fix_fields, pattern is made to point to this string (tmp_value). In further processing, tmp_value is getting modified which causes pattern to have changed/wrong values. Fix: Allocate its own memroy location in caller, copy value of resultant string (tmp_value) into that and make pattern to point to that. This makes sure no further changes to tmp_value will affect pattern.
-
- 25 Jan, 2012 1 commit
-
-
Tor Didriksen authored
Bug#11758543 50756: BIGINT '100' MATCHES 1.001E2 Expressions of the form BIGINT_COL <compare> <non-integer constant> should be done either as decimal, or float. Currently however, such comparisons are done as int, which means that the constant may be truncated, and yield false positives/negatives for all queries where compare is '>' '<' '>=' '<=' '=' '!='. BIGINT_COL IN <list of contstants> and BIGINT_COL BETWEEN <constant> AND <constant> are also affected. mysql-test/r/bigint.result: New tests. mysql-test/r/func_in.result: BIGINT <=> string comparison should be done as float, so a warning for the value 'abc' is appropriate. mysql-test/t/bigint.test: New tests. sql/item_cmpfunc.cc: In convert_constant_item() we verify that the constant item can be stored in the given field. For BIGINT columns (MYSQL_TYPE_LONGLONG) we must verify that the stored constant value is actually comparable as int, i.e. that the value was not truncated. For between: compare as int only if both arguments convert correctly to int.
-
- 19 Aug, 2011 1 commit
-
-
Tor Didriksen authored
Bug#12532830 - SIGFPE OR ASSERTION (PRECISION <= ((9 * 9) - 8*2)) && (DEC <= 30)
-
- 30 Jun, 2011 1 commit
-
-
Kent Boortz authored
-
- 21 Jun, 2011 1 commit
-
-
Alexander Nozdrin authored
OLD VALUE OF INPUT PARAMETER. The user-visible problem was that CASE-control-flow function (not CASE-statement) misbehaved in stored routines under some circumstances. The problem resulted in a crash or wrong data returned. The error happened when expressions in CASE-function were not of the same character set. A CASE-function should return values of the same character set for all branches. Internally, that means a new Item-instance for the CONVERT(... USING <some charset>)-function is added to the item tree when needed. The problem was that such changes were not properly recorded using THD::change_item_tree(), thus dangling pointers remain in the item tree after THD::rollback_item_tree_changes(), which lead to undefined behavior (i.e. crash / wrong data) for subsequent executions of the stored routine. This bug was introduced by a patch for Bug 11753363 (44793 - CHARACTER SETS: CASE CLAUSE, UCS2 OR UTF32, FAILURE). The fixed function is Item_func_case::fix_length_and_dec(). New CONVERT-items are added in agg_item_set_converter(), which calls THD::change_item_tree(). The problem was that an intermediate array was passed to agg_item_set_converter(). Thus, THD::change_item_tree() there was called on intermediate objects. Note: those intermediate objects are allocated on THD's memory root, so it's Ok to put them into "changed item lists". The fix is to track changes on the correct objects.
-
- 06 May, 2011 1 commit
-
-
Alexander Nozdrin authored
(SUBSTRING inside a stored function works too slow). Background: - THD classes derives from Query_arena, thus inherits the 'state' attribute and related operations (is_stmt_prepare() & co). - Although these operations are available in THD, they must not be used. THD has its own attribute to point to the active Query_arena -- stmt_arena. - So, instead of using thd->is_stmt_prepare(), thd->stmt_arena->is_stmt_prepare() must be used. This was the root cause of Bug 60025. This patch enforces the proper way of calling those operations. is_stmt_prepare() & co are declared as private operations in THD (thus, they are hidden from being called on THD instance). The patch tries to minimize changes in 5.5.
-
- 12 Apr, 2011 1 commit
-
-
Sergey Glukhov authored
Valgrind warning happens due to early null values check in Item_func_in::fix_length_and_dec(before item evaluation). As result null value items with uninitialized values are placed into array and it leads to valgrind warnings during value array sorting. The fix is to check null value after item evaluation, item is evaluated in in_array::set() method. mysql-test/r/func_in.result: test case mysql-test/t/func_in.test: test case sql/item_cmpfunc.cc: The fix is to check null value after item evaluation.
-
- 01 Mar, 2011 1 commit
-
-
Alexander Barkov authored
Problem: in case of string CASE/WHEN arguments with different character sets, Item_func_case::find_item() called comparator cmp_items[x] on mixed character set Items, so a 8-bit value could be errouneously referenced to as being utf16/utf32 value, which led to crash on DBUG_ASSERT() because of wrong value length. This was wrong, as string comparator expects arguments in the same character set. Fix: modify Item_func_case's argument list after calling agg_arg_charsets_for_comparison() - put the Items in "agg" array back to "args", because some of the Items in the "agg" array might have been changed to character set converters: - to Item_func_conv_charset for non-constant items - to Item_string for constant items In other words, perform the same substitution which is done in all other operations string comparison or string result operations: Replace CASE latin1_item WHEN utf16_item THEN ... END to CASE CONVERT(latin1_item USING utf16) WHEN utf16_item THEN ... END Replace CASE utf16_item WHEN latin1_item THEN ... END to CASE utf16_item WHEN CONVERT(latin1_item USING utf16) THEN ... END @ mysql-test/r/ctype_utf16.result @ mysql-test/r/ctype_utf32.result @ mysql-test/t/ctype_utf16.test @ mysql-test/t/ctype_utf32.test Adding tests @ sql/item_cmpfunc.cc Put "agg" back to "args". @ sql/sql_string.cc Backporting a fix for String::set_or_copy_aligned() from 5.6, for better test coverage: "SELECT _utf16 0x61" should expand the string to 0x0061 rather than to 0x000061. This fix was made in 5.6 under terms of "WL#4616 Implement UTF16-LE".
-
- 18 Feb, 2011 1 commit
-
-
Alexander Barkov authored
Problem: IF() did not copy collation derivation and repertoire from an argument if the opposite argument was NULL: IF(cond, res1, NULL) IF(cond, NULL, res2) only CHARSET_INFO pointer was copied. This resulted in illegal mix of collations error. Fix: copy all collation parameters from the non-NULL argument: CHARSET_INFO pointer, derivation, repertoire.
-
- 17 Feb, 2011 2 commits
-
-
Tor Didriksen authored
See also bug 11775312, all queries listed there now have the same results here, as they have in 5.1
-
Tor Didriksen authored
This assumption in Item_cache_datetime::cache_value_int was wrong: - /* Assume here that the underlying item will do correct conversion.*/ - int_value= example->val_int_result(); mysql-test/r/subselect_innodb.result: New test case. mysql-test/t/subselect_innodb.test: New test case. sql/item.cc: In Item_cache_datetime::cache_value_int() - call get_time() or get_date() depending on desired type - convert the returned MYSQL_TIME value to longlong depending on desired type sql/item.h: The cached int_value in Item_cache_datetime should not be unsigned: - it is used mostly in signed context - it can actually have negative value (for TIME data type) sql/item_cmpfunc.cc: Add comment on Bug#59685 sql/item_subselect.cc: Add some DBUG_TRACE for easier bug-hunting.
-
- 11 Feb, 2011 1 commit
-
-
Sergey Glukhov authored
The crash happens because Item_cache which is result holder for Item_subselect can't correctly convert a DATETIME value from string to int representation. The fix is to disable constant item convertion for subselect(partial rollback of bug52157 fix). mysql-test/r/type_date.result: test case mysql-test/t/type_date.test: test case sql/item_cmpfunc.cc: disable constant item convertion for subselects.
-
- 09 Feb, 2011 2 commits
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3520 > revision-id: sergey.glukhov@oracle.com-20101214093303-wmo9mqcb8rz0wv9f > parent: tor.didriksen@oracle.com-20101213161301-81lprlbune7r98dl > committer: Sergey Glukhov <sergey.glukhov@oracle.com> > branch nick: mysql-5.1-bugteam > timestamp: Tue 2010-12-14 12:33:03 +0300 > message: > 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 Build Team authored
> ------------------------------------------------------------ > revno: 3452.13.54 > revision-id: oystein.grovlen@oracle.com-20110112093715-tc076voaxwblqk8v > parent: georgi.kodinov@oracle.com-20110110130833-1c9q21mr7zoq07vg > committer: Oystein Grovlen <oystein.grovlen@oracle.com> > branch nick: mysql-5.1-security > timestamp: Wed 2011-01-12 10:37:15 +0100 > message: > Bug#59211: Select Returns Different Value for min(year) Function > > get_year_value() contains code to convert 2-digits year to > 4-digits. The fix for Bug#49910 added a check on the size of > the underlying field so that this conversion is not done for > YEAR(4) values. (Since otherwise one would convert invalid > YEAR(4) values to valid ones.) > > The existing check does not work when Item_cache is used, since > it is not detected when the cache is based on a Field. The > reported change in behavior is due to Bug#58030 which added > extra cached items in min/max computations. > > The elegant solution would be to implement > Item_cache::real_item() to return the underlying Item. > However, some side effects are observed (change in explain > output) that indicates that such a change is not straight- > forward, and definitely not appropriate for an MRU. > > Instead, a Item_cache::field() method has been added in order > to get access to the underlying field. (This field() method > eliminates the need for Item_cache::eq_def() used in > test_if_ref(), but in order to limit the scope of this fix, > that code has been left as is.)
-
- 25 Jan, 2011 1 commit
-
-
Karen Langford authored
-
- 19 Jan, 2011 1 commit
-
-
Martin Hansson authored
ZERO When dates are represented internally as strings, i.e. when a string constant is compared to a date value, both values are converted to long integers, ostensibly for fast comparisons. DATE typed integer values are converted to DATETIME by multiplying by 1,000,000 (each digit pair representing hour, minute and second, respectively). But the mechanism did not distuinguish cached INTEGER values, already in correct format, from newly converted strings. Fixed by marking the INTEGER cache as being of DATETIME format.
-
- 14 Jan, 2011 1 commit
-
-
Tor Didriksen authored
Fix: copy my_decimal by value, to avoid dangling pointers. mysql-test/r/func_math.result: New test case. mysql-test/t/func_math.test: New test case. sql/item_cmpfunc.cc: No need to call fix_buffer_pointer() anymore. sql/item_func.cc: Copy my_decimal by value, to avoid dangling pointers. sql/my_decimal.h: Implement proper copy constructor and assignment operator for my_decimal. sql/sql_analyse.cc: No need to call fix_buffer_pointer() anymore. strings/decimal.c: Remove #line directive: it messes up TAGS and it confuses gdb when debugging.
-
- 13 Jan, 2011 1 commit
-
-
Ole John Aske authored
Item_equal::val_int() checked for NULL-values by checking Item::null_value *before* the respective ::store_value() and ::cmp(Item*) metods where called. As Item::null_value is set by these metods, the value of 'null_value' is not valid until *after* ::store_value() or ::cmp() has been called for the Item object. Fix is to swap order of ::store_value()/::cmp() and checking of Item::null_value. This pattern is widely used other places inside item_cmpfunc.cc .
-
- 12 Jan, 2011 1 commit
-
-
Oystein Grovlen authored
get_year_value() contains code to convert 2-digits year to 4-digits. The fix for Bug#49910 added a check on the size of the underlying field so that this conversion is not done for YEAR(4) values. (Since otherwise one would convert invalid YEAR(4) values to valid ones.) The existing check does not work when Item_cache is used, since it is not detected when the cache is based on a Field. The reported change in behavior is due to Bug#58030 which added extra cached items in min/max computations. The elegant solution would be to implement Item_cache::real_item() to return the underlying Item. However, some side effects are observed (change in explain output) that indicates that such a change is not straight- forward, and definitely not appropriate for an MRU. Instead, a Item_cache::field() method has been added in order to get access to the underlying field. (This field() method eliminates the need for Item_cache::eq_def() used in test_if_ref(), but in order to limit the scope of this fix, that code has been left as is.) mysql-test/r/type_year.result: Added test case for Bug#59211. mysql-test/t/type_year.test: Added test case for Bug#59211. sql/item.h: Added function Item_cache::field() to get access to the underlying Field of a cached field Value. sql/item_cmpfunc.cc: Also check underlying fields of Item_cache, not just Item_Field, when checking whether the value is of type YEAR(4) or not.
-
- 28 Dec, 2010 1 commit
-
-
Kent Boortz authored
- Removed files specific to compiling on OS/2 - Removed files specific to SCO Unix packaging - Removed "libmysqld/copyright", text is included in documentation - Removed LaTeX headers for NDB Doxygen documentation - Removed obsolete NDB files - Removed "mkisofs" binaries - Removed the "cvs2cl.pl" script - Changed a few GPL texts to use "program" instead of "library"
-
- 16 Dec, 2010 1 commit
-
-
Martin Hansson authored
file .\item_subselect.cc, line 836 IN quantified predicates are never executed directly. They are rather wrapped inside nodes called IN Optimizers (Item_in_optimizer) which take care of the execution. However, this is not done during query preparation. Unfortunately the LIKE predicate pre-evaluates constant right-hand side arguments even during name resolution. Likely this is meant as an optimization. Fixed by not pre-evaluating LIKE arguments in view prepare mode. Back-ported to 5.0s
-
- 14 Dec, 2010 1 commit
-
-
Sergey Glukhov authored
--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
-
- 18 Nov, 2010 1 commit
-
-
Sergey Glukhov authored
ESCAPE argument might be empty string. It leads to server crash under some circumstances. The fix: -added check if ESCAPE argument result is not empty string mysql-test/r/ctype_latin1.result: test case mysql-test/t/ctype_latin1.test: test case sql/item_cmpfunc.cc: -added check if ESCAPE argument result is not empty string
-
- 08 Nov, 2010 1 commit
-
-
Sergey Glukhov authored
Problem: a flaw (derefencing a NULL pointer) in the LIKE optimization code may lead to a server crash in some rare cases. Fix: check the pointer before its dereferencing. mysql-test/r/func_like.result: Fix for bug #54575: crash when joining tables with unique set column - test result. mysql-test/t/func_like.test: Fix for bug #54575: crash when joining tables with unique set column - test case. sql/item_cmpfunc.cc: Fix for bug #54575: crash when joining tables with unique set column - check res2 buffer pointer before its dereferencing as it may be NULL in some cases.
-
- 06 Oct, 2010 1 commit
-
-
Alexander Barkov authored
Problem: CASE didn't work with a mixture of different character sets in THEN/ELSE in some cases. This happened because after character set aggregation newly created Item_func_conv_charset items corresponding to THEN/ELSE arguments were not put back to args[] array. Fix: put all Item_func_conv_charset back to args[]. @ mysql-test/include/ctype_numconv.inc @ mysql-test/r/ctype_ucs.result Adding tests @ sql/item_cmpfunc.cc Put "agg" back to args[] after character set aggregation.
-
- 09 Sep, 2010 1 commit
-
-
Alexey Kopytov authored
result Row subqueries producing no rows were not handled as UNKNOWN values in row comparison expressions. That was a result of the following two problems: 1. Item_singlerow_subselect did not mark the resulting row value as NULL/UNKNOWN when no rows were produced. 2. Arg_comparator::compare_row() did not take into account that a whole argument may be NULL rather than just individual scalar values. Before bug#34384 was fixed, the above problems were hidden because an uninitialized (i.e. without any stored value) cached object would appear as NULL for scalar values in a row subquery returning an empty result. After the fix Arg_comparator::compare_row() would try to evaluate uninitialized cached objects. Fixed by removing the aforementioned problems. mysql-test/r/row.result: Added a test case for bug #54190. mysql-test/r/subselect.result: Updated the result for a test relying on wrong behavior. mysql-test/t/row.test: Added a test case for bug #54190. sql/item_cmpfunc.cc: If either of the argument rows is NULL, return NULL as the result of comparison. sql/item_subselect.cc: Adjust null_value for Item_singlerow_subselect depending on whether a row has been produced by the row subquery.
-
- 07 Sep, 2010 1 commit
-
-
Martin Hansson authored
The EXISTS transformation has additional switches to catch the known corner cases that appear when transforming an IN predicate into EXISTS. Guarded conditions are used which are deactivated when a NULL value is seen in the outer expression's row. When the inner query block supplies NULL values, however, they are filtered out because no distinction is made between the guarded conditions; guarded NOT x IS NULL conditions in the HAVING clause that filter out NULL values cannot be de-activated in isolation from those that match values or from the outer expression or NULL's. The above problem is handled by making the guarded conditions remember whether they have rejected a NULL value or not, and index access methods are taking this into account as well. The bug consisted of 1) Not resetting the property for every nested loop iteration on the inner query's result. 2) Not propagating the NULL result properly from inner query to IN optimizer. 3) A hack that may or may not have been needed at some point. According to a comment it was aimed to fix #2 by returning NULL when FALSE was actually the result. This caused failures when #2 was properly fixed. The hack is now removed. The fix resolves all three points.
-
- 25 Aug, 2010 1 commit
-
-
Alexey Kopytov authored
file .\dtoa.c The assertion failure was correct because the 'width' argument of my_gcvt() has the signed integer type, whereas the unsigned value UINT_MAX32 was being passed by the caller (Field_double::val_str()) leading to a negative width in my_gcvt(). The following chain of problems was found by further analysis: 1. The display width for a floating point number is calculated in Field_double::val_str() as either field_length or the maximum possible length of string representation of a floating point number, whichever is greater. Since in the bug's test case field_length is UINT_MAX32, we get the same value as the display width. This does not make any sense because for numeric values field_length only matters for ZEROFILL columns, otherwise it does not make sense to allocate that much memory just to print a number. Field_float::val_str() has a similar problem. 2. Even if the above wasn't the case, we would still get a crash on a slightly different test case when trying to allocate UINT_MAX32 bytes with String::alloc() because the latter does not handle such large input values correctly due to alignment overflows. 3. Even when String::alloc() is fixed to return an error when an alignment overflow occurs, there is still a problem because almost no callers check its return value, and Field_double::val_str() is not an exception (same for Field_float::val_str()). 4. Even if all of the above wasn't the case, creating a Field_double object with UINT_MAX32 as its field_length does not make much sense either, since the .frm code limits it to MAX_FIELD_CHARLENGTH (255) bytes. Such a beast can only be created by create_tmp_field_from_item() from an Item with REAL_RESULT as its result_type() and UINT_MAX32 as its max_length. 5. For the bug's test case, the above condition (REAL_RESULT Item with max_length = UINT_MAX32) was a result of Item_func_if::fix_length_and_dec() "shortcutting" aggregation of argument types when one of the arguments was a constant NULL. In this case, the attributes of the aggregated type were simply copied from the other, non-NULL argument, but max_length was still calculated as per the general, non-shortcut case, by choosing the greatest of argument's max_length, which is obviously not correct. The patch addresses all of the above problems, even though fixing the assertion failure for the particular test case would require only a subset of the above problems to be solved. client/sql_string.cc: Return an error in case of uint32 overflow in alignment. Also assert there was no overflow to help find such conditions in debug builds, since almost no callers check the return value of String::alloc(). mysql-test/r/func_if.result: Add a test case for bug #55077. mysql-test/t/func_if.test: Add a test case for bug #55077. sql/field.cc: - Assert we don't operate with fields wider than 255 (MAX_FIELD_CHARLENGTH) bytes in both Field_float and Field_double. - Don't take field_length into account when calculating the output buffer length. - Check the return value of String::alloc() sql/item_cmpfunc.cc: When shortcutting type aggregation, don't take the NULL argument's max_length into account. sql/sql_string.cc: Return an error in case of uint32 overflow in alignment. Also assert there was no overflow to help find such conditions in debug builds, since almost no callers check the return value of String::alloc().
-
- 19 Aug, 2010 1 commit
-
-
Alexander Barkov authored
Problem: a few functions did not calculate their max_length correctly. This is an after-fix for WL#2649 Number-to-string conversions". Fix: changing the buggy functions to calculate max_length using fix_char_length() introduced in WL#2649, instead of setting max_length directly mysql-test/include/ctype_numconv.inc Adding new tests mysql-test/r/ctype_binary.result Adding new tests mysql-test/r/ctype_cp1251.result Adding new tests mysql-test/r/ctype_latin1.result Adding new tests mysql-test/r/ctype_ucs.result Adding new tests mysql-test/r/ctype_utf8.result Adding new tests mysql-test/t/ctype_utf8.test Including ctype_numconv sql/item.h - Introducing new method fix_char_length_ulonglong(), for the cases when length is potentially greater than UINT_MAX32. This method removes a few instances of duplicate code, e.g. in item_strfunc.cc. - Setting collation in Item_copy properly. This change fixes wrong metadata on client side in some cases, when "binary" instead of the real character set was reported. sql/item_cmpfunc.cc - Using fix_char_length() and max_char_length() methods, instead of direct access to max_length, to calculate item length properly. - Moving count_only_length() in COALESCE after agg_arg_charsets_for_string_result(). The old order was incorrect and led to wrong length calucation in case of multi-byte character sets. sql/item_func.cc Fixing that count_only_length() didn't work properly for multi-byte character sets. Using fix_char_length() and max_char_length() instead of direct access to max_length. sql/item_strfunc.cc - Using fix_char_length(), fix_char_length_ulonglong(), max_char_length() instead of direct access to max_length. - Removing wierd condition: "if (collation.collation->mbmaxlen > 0)", which is never FALSE.
-
- 05 Aug, 2010 1 commit
-
-
Martin Hansson authored
file .\item_subselect.cc, line 836 IN quantified predicates are never executed directly. They are rather wrapped inside nodes called IN Optimizers (Item_in_optimizer) which take care of the execution. However, this is not done during query preparation. Unfortunately the LIKE predicate pre-evaluates constant right-hand side arguments even during name resolution. Likely this is meant as an optimization. Fixed by not pre-evaluating LIKE arguments in view prepare mode.
-
- 23 Jul, 2010 1 commit
-
-
Davi Arnaut authored
Remove unused macros or macro which are always defined. include/my_global.h: Remove unused macros and move macros which aren't used globally.
-
- 19 Jul, 2010 1 commit
-
-
Evgeny Potemkin authored
This bug is a design flaw of the fix for the bug#33546. It assumed that an item can be used only in one comparison context, but actually it isn't the case. Item_cache_datetime is used to store result for MIX/MAX aggregate functions. Because Arg_comparator always compares datetime values as INTs when possible the Item_cache_datetime most time caches only INT value. But since all datetime values has STRING result type MIN/MAX functions are asked for a STRING value when the result is being sent to a client. The Item_cache_datetime was designed to avoid conversions and get INT/STRING values from an underlying item, but at the moment the values is asked underlying item doesn't hold it anymore thus wrong result is returned. Beside that MIN/MAX aggregate functions was wrongly initializing cached result and this led to a wrong result. The Item::has_compatible_context helper function is added. It checks whether this and given items has the same comparison context or can be compared as DATETIME values by Arg_comparator. The equality propagation optimization is adjusted to take into account that items which being compared as DATETIME can have different comparison contexts. The Item_cache_datetime now converts cached INT value to a correct STRING DATETIME value by means of number_to_datetime & my_TIME_to_str functions. The Arg_comparator::set_cmp_context_for_datetime helper function is added. It sets comparison context of items being compared as DATETIMEs to INT if items will be compared as longlong. The Item_sum_hybrid::setup function now correctly initializes its result value. In order to avoid unnecessary conversions Item_sum_hybrid now states that it can provide correct longlong value if the item being aggregated can do it too. mysql-test/r/group_by.result: Added a test case for the bug#49771. sql/item.cc: Bug#49771: Incorrect MIN/MAX for date/time values. The equality propagation mechanism is adjusted to take into account that items which being compared as DATETIME can have different comparison contexts. The Item_cache_datetime now converts cached INT value to a correct STRING DATETIME/TIME value. sql/item.h: Bug#49771: Incorrect MIN/MAX for date/time values. The Item::has_compatible_context helper function is added. It checks whether this and given items has the same comparison context or can be compared as DATETIME values by Arg_comparator. Added Item_cache::clear helper function. sql/item_cmpfunc.cc: Bug#49771: Incorrect MIN/MAX for date/time values. The Arg_comparator::set_cmp_func now sets the correct comparison context for items being compared as DATETIME values. sql/item_cmpfunc.h: Bug#49771: Incorrect MIN/MAX for date/time values. The Arg_comparator::set_cmp_context_for_datetime helper function is added. It sets comparison context of items being compared as DATETIMEs to INT if items will be compared as longlong. sql/item_sum.cc: Bug#49771: Incorrect MIN/MAX for date/time values. The Item_sum_hybrid::setup function now correctly initializes its result value. sql/item_sum.h: Bug#49771: Incorrect MIN/MAX for date/time values. In order to avoid unnecessary conversions Item_sum_hybrid now states that it can provide correct longlong value if the item being aggregated can do it too.
-
- 22 Jun, 2010 1 commit
-
-
Alexey Kopytov authored
Incorrect handling of NULL arguments could lead to a crash on the IN or CASE operations when either NULL arguments were passed explicitly as arguments (IN) or implicitly generated by the WITH ROLLUP modifier (both IN and CASE). Item_func_case::find_item() assumed all necessary comparators to be instantiated in fix_length_and_dec(). However, in the presence of WITH ROLLUP modifier, arguments could be substituted with an Item_null leading to an "unexpected" STRING_RESULT comparator being invoked. In addition to the problem identical to the above, Item_func_in::val_int() could crash even with explicitly passed NULL arguments due to an optimization in fix_length_and_dec() leading to NULL arguments being ignored during comparators creation. mysql-test/r/func_in.result: Test cases for bug#54477. mysql-test/t/func_in.test: Test cases for bug#54477. sql/item_cmpfunc.cc: Added additional checks for Item_nulls in Item_func_case::find_item() and Item_func_in::val_int().
-
- 19 Jun, 2010 1 commit
-
-
Ramil Kalimullin authored
Problem: a flaw (derefencing a NULL pointer) in the LIKE optimization code may lead to a server crash in some rare cases. Fix: check the pointer before its dereferencing. mysql-test/r/func_like.result: Fix for bug #54575: crash when joining tables with unique set column - test result. mysql-test/t/func_like.test: Fix for bug #54575: crash when joining tables with unique set column - test case. sql/item_cmpfunc.cc: Fix for bug #54575: crash when joining tables with unique set column - check res2 buffer pointer before its dereferencing as it may be NULL in some cases.
-
- 31 May, 2010 1 commit
-
-
Gleb Shchepa authored
when it should use index Sometimes the LEFT/RIGHT JOIN with an empty table caused an unnecessary filesort. Sample query, where t1.i1 is indexed and t3 is empty: SELECT t1.*, t2.* FROM t1 JOIN t2 ON t1.i1 = t2.i2 LEFT JOIN t3 ON t2.i2 = t3.i3 ORDER BY t1.i1 LIMIT 5; The server erroneously used an item of empty outer-joined table as a common constant of a Item_equal (multi-equivalence expression). By the fix for the bug 16590 the constant status of such an item has been propagated to st_table::const_key_parts map bits related to other Item_equal argument-related key parts (those are obviously not constant in our case). As far as test_if_skip_sort_order function skips constant prefixes of testing keys, this caused an ignorance of available indices, since some prefixes were marked as constant by mistake. mysql-test/r/order_by.result: Test case for bug #38745. mysql-test/t/order_by.test: Test case for bug #38745. sql/item.h: Bug #38745: MySQL 5.1 optimizer uses filesort for ORDER BY when it should use index Item::is_outer_field() has been added and overloaded for Item_field and Item_ref classes. sql/item_cmpfunc.cc: Bug #38745: MySQL 5.1 optimizer uses filesort for ORDER BY when it should use index Item_equal::update_const() and Item_equal::update_used_tables() have been updated to not take into account the constantness of outer-joined table items.
-
- 31 Mar, 2010 1 commit
-
-
Mats Kindahl authored
This patch: - Moves all definitions from the mysql_priv.h file into header files for the component where the variable is defined - Creates header files if the component lacks one - Eliminates all include directives from mysql_priv.h - Eliminates all circular include cycles - Rename time.cc to sql_time.cc - Rename mysql_priv.h to sql_priv.h
-