An error occurred fetching the project authors.
- 13 Mar, 2013 1 commit
-
-
Sergei Golubchik authored
get_datetime_value() should not double-cache its own Item_cache_temporal items, but it *should* cache other Item_cache items, such as Item_cache_str. sql/item.h: shortcut, to avoid going through the switch in Item::cmp_type() sql/item_cmpfunc.cc: even if the item is Item_cache_str - it still needs to be converted and cached. sql/item_timefunc.h: all descendants of Item_temporal_func always have cmp_type==TIME_RESULT. Even Item_date_add_interval, that might have field_type == MYSQL_TYPE_STRING.
-
- 11 Mar, 2013 1 commit
-
-
Igor Babaev authored
-
- 25 Feb, 2013 2 commits
-
-
unknown authored
-
Igor Babaev authored
The function remove_eq_cond removes the parts of a disjunction for which it has been proved that they are always true. In the result of this removal the disjunction may be converted into a formula without OR that must be merged into the the AND formula that contains the disjunction. The merging of two AND conditions must take into account the multiple equalities that may be part of each of them. These multiple equality must be merged and become part of the and object built as the result of the merge of the AND conditions. Erroneously the function remove_eq_cond lacked the code that would merge multiple equalities of the merged AND conditions. This could lead to confusing situations when at the same AND level there were two multiple equalities with common members and the list of equal items contained only some of these multiple equalities. This, in its turn, could lead to an incorrect work of the function substitute_for_best_equal_field when it tried to optimize ref accesses. This resulted in forming invalid TABLE_REF objects that were used to build look-up keys when materialized subqueries were exploited.
-
- 22 Feb, 2013 1 commit
-
-
Igor Babaev authored
This bug in the legacy code could manifest itself in queries with semi-join materialized subqueries. When a subquery is materialized all conditions that are imposed only on the columns belonging to the tables from the subquery are taken into account.The code responsible for subquery optimizations that employes subquery materialization makes sure to remove these conditions from the WHERE conditions of the query obtained after it has transformed the original query into a query with a semi-join. If the condition to be removed is an equality condition it could be added to ON expressions and/or conditions from disjunctive branches (parts of OR conditions) in an attempt to generate better access keys to the tables of the query. Such equalities are supposed to be removed later from all the formulas where they have been added to. However, erroneously, this was not done in some cases when an ON expression and/or a disjunctive part of the OR condition could be converted into one multiple equality. As a result some equality predicates over columns belonging to the tables of the materialized subquery remained in the ON condition and/or the a disjunctive part of the OR condition, and the excuter later, when trying to evaluate them, returned wrong answers as the values of the fields from these equalities were not valid. This happened because any standalone multiple equality (a multiple equality that are not ANDed with any other predicates) lacked the information about equality predicates inherited from upper levels (in particular, inherited from the WHERE condition). The fix adds a reference to such information to any standalone multiple equality.
-
- 28 Dec, 2012 1 commit
-
-
unknown authored
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.
-
- 23 Dec, 2012 1 commit
-
-
unknown authored
-
- 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.
-
- 19 Dec, 2012 1 commit
-
-
unknown authored
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.
-
- 28 Sep, 2012 1 commit
-
-
unknown authored
MDEV-127 Optimization of memory allocation MDEV-483 Make column_check function which cheсks dynamic columns integrit JSON conversion function
-
- 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
-
- 21 Jun, 2012 1 commit
-
-
unknown authored
We set correct cmp_context during preparation to avoid changing it later by Item_field::equal_fields_propagator. (see mysql bugs #57135 #57692 during merging)
-
- 15 Jun, 2012 1 commit
-
-
Sergei Golubchik authored
make sure that find_date_time_item() is called before agg_arg_charsets_for_comparison(). optimize Item_func_conv_charset to avoid conversion if no string result is needed
-
- 30 May, 2012 1 commit
-
-
unknown authored
Analysis: When a subquery that needs a temp table is executed during the prepare or optimize phase of the outer query, at the end of the subquery execution all the JOIN_TABs of the subquery are replaced by a new JOIN_TAB that selects from the temp table. However that temp table has no corresponding TABLE_LIST. Once EXPLAIN execution reaches its last phase, it tries to print the names of the subquery tables through its TABLE_LISTs, but in the case of this bug there is no such TABLE_LIST (it is NULL), hence a crash. Solution: The fix is to block subquery evaluation inside Item_func_like::fix_fields and Item_func_like::select_optimize() using the Item::is_expensive() test.
-
- 25 May, 2012 1 commit
-
-
unknown authored
The problem is that some fix_fields do not call Item_func::fix_fields and do not collect with subselect_information.
-
- 24 May, 2012 1 commit
-
-
unknown authored
Analysis: The problem in the original MySQL bug is that the range optimizer performs its analysis in a separate MEM_ROOT object that is freed after the range optimzier is done. During range analysis get_mm_tree calls Item_func_like::select_optimize, which in turn evaluates its right argument. In the test case the right argument is a subquery. In MySQL, subqueries are optimized lazyly, thus the call to val_str triggers optimization for the subquery. All objects needed by the subquery plan end up in the temporary MEM_ROOT used by the range optimizer. When execution ends, the JOIN::cleanup process tries to cleanup objects of the subquery plan, but all these objects are gone with the temporary MEM_ROOT. The solution for MySQL is to switch the mem_root. In MariaDB with the patch for bug lp:944706, all constant subqueries that may be used by the optimization process are preoptimized. Therefore Item_func_like::select_optimize only triggers subquery execution, and the above problem is not present. The patch however adds a test whether the evaluated right argument of the LIKE predicate is expensive. This is consistent with our approach not to evaluate expensive expressions during optimization.
-
- 22 May, 2012 1 commit
-
-
unknown authored
The problem is that some fix_fields do not call Item_func::fix_fields and do not collect with subselect_information.
-
- 17 May, 2012 3 commits
-
-
unknown authored
The patch enables back constant subquery execution during query optimization after it was disabled during the development of MWL#89 (cost-based choice of IN-TO-EXISTS vs MATERIALIZATION). The main idea is that constant subqueries are allowed to be executed during optimization if their execution is not expensive. The approach is as follows: - Constant subqueries are recursively optimized in the beginning of JOIN::optimize of the outer query. This is done by the new method JOIN::optimize_constant_subqueries(). This is done so that the cost of executing these queries can be estimated. - Optimization of the outer query proceeds normally. During this phase the optimizer may request execution of non-expensive constant subqueries. Each place where the optimizer may potentially execute an expensive expression is guarded with the predicate Item::is_expensive(). - The implementation of Item_subselect::is_expensive has been extended to use the number of examined rows (estimated by the optimizer) as a way to determine whether the subquery is expensive or not. - The new system variable "expensive_subquery_limit" controls how many examined rows are considered to be not expensive. The default is 100. In addition, multiple changes were needed to make this solution work in the light of the changes made by MWL#89. These changes were needed to fix various crashes and wrong results, and legacy bugs discovered during development.
-
unknown authored
The problem is that we can't check null_value field of non-basic constant without the item execution.:
-
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.
-
- 26 Mar, 2012 1 commit
-
-
Sergey Petrunya authored
BUG#951937: Wrong result (missing rows) with semijoin+materialization, IN subquery, InnoDB, TEMPTABLE view - Fix equality propagation to work with SJM nests and OR clauses (full descirption of problem and solution in the comment in the patch) (The second commit with post-review fixes)
-
- 28 Feb, 2012 1 commit
-
-
Sergei Golubchik authored
make sure that stored routines are evaluated (that is, de facto - cached) in convert_const_to_int(). revert the fix for lp:806943 because it cannot be repeated anymore. add few tests for convert_const_to_int()
-
- 27 Jan, 2012 1 commit
-
-
Sergey Petrunya authored
BUG#922254: Assertion `0' failed at item_cmpfunc.cc:5899: Item* Item_equal::get_first(JOIN_TAB*, Item*) Fixed Item* Item_equal::get_first(JOIN_TAB *context, Item *field_item) to work correctly in the case where: - context!= NO_PARTICULAR_TAB, it points to a table within SJ-Materialization nest - field_item points to an item_equal that has a constant Item_field but does not have any fields from tables that are within semi-join nests.
-
- 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 Jan, 2012 1 commit
-
-
Sergey Petrunya authored
- equality substitution code was geared towards processing WHERE/ON clauses. that is, it assumed that it was doing substitions on the code that = wasn't attached to any particular join_tab yet = was going to be fed to make_join_select() which would take the condition apart and attach various parts of it to tables inside/outside semi-joins. - However, somebody added equality substition for ref access. That is, if we have a ref access on TBL.key=expr, they would do equality substition in 'expr'. This possibility wasn't accounted for. - Fixed equality substition code by adding a mode that does equality substition under assumption that the processed expression will be attached to a certain particular table TBL.
-
- 13 Nov, 2011 1 commit
-
-
unknown authored
Fix for walk() method of subqueries: always call the method on the subquery.
-
- 01 Nov, 2011 1 commit
-
-
unknown authored
-
- 26 Oct, 2011 1 commit
-
-
Sergey Petrunya authored
-
- 02 Nov, 2011 1 commit
-
-
Sergei Golubchik authored
-
- 23 Oct, 2011 1 commit
-
-
Igor Babaev authored
This bug happened because the function Item_cond::eval_not_null_tables erroneously did not initialize the value of not_null_tables_cache.
-
- 18 Oct, 2011 1 commit
-
-
unknown authored
-
- 13 Oct, 2011 1 commit
-
-
Sergei Golubchik authored
restore the status quo from before the microsecond patch
-
- 22 Sep, 2011 1 commit
-
-
Sergey Petrunya authored
- Provide fix_after_pullout() function for Item_in_optimizer and other Item_XXX classes (basically, all of them that have eval_not_null_tables, which means they have special rules for calculating not_null_tables_cache value)
-
- 07 Sep, 2011 1 commit
-
-
Sergei Golubchik authored
remove incorrect DBUG_ASSERT(). Fix incorrectly used cmp_item::get_comparator() in Item_func_case and Item_equal
-
- 05 Sep, 2011 1 commit
-
-
unknown authored
ALL subquery should return TRUE if subquery rowa set is empty independently of left part. The problem was that Item_func_(eq,ne,gt,ge,lt,le) do not call execution of second argument if first is NULL no in this case subquery will not be executed and when Item_func_not_all calls any_value() of the subquery or aggregation function which report that there was rows. So for NULL < ALL (SELECT...) result was FALSE instead of TRUE. Fix is just swapping of arguments of Item_func_(eq,ne,gt,ge,lt,le) (with changing the operation if it is needed) so that result will be the same (for examole a < b is equal to b > a). This fix exploit the fact that first argument will be executed in any case.
-
- 29 Aug, 2011 1 commit
-
-
Sergey Petrunya authored
- The problem was that the code that made the check whether the subquery is an AND-part of the WHERE clause didn't work correctly for nested subqueries. In particular, grand-child subquery in HAVING was treated as if it was in the WHERE, which eventually caused an assert when replace_where_subcondition looked for the subquery predicate in the WHERE and couldn't find it there. - The fix: Removed implementation of "thd_marker approach". thd->thd_marker was used to determine the location of subquery predicate: setup_conds() would set accordingly it when making the {where|on_expr}->fix_fields(...) call so that AND-parts of the WHERE/ON clauses can determine they are the AND-parts. Item_cond_or::fix_fields(), Item_func::fix_fields(), Item_subselect::fix_fields (this one was missed), and all other items-that-contain-items had to reset thd->thd_marker before calling fix_fields() for their children items, so that the children can see they are not AND-parts of WHERE/ON. - The "thd_marker approach" required that a lot of code in different locations maintains correct value of thd->thd_marker, so it was replaced with: - The new approach with mark_as_condition_AND_part does not keep context in thd->thd_marker. Instead, setup_conds() now calls {where|on_expr}->mark_as_condition_AND_part() and implementations of that function make sure that: - parts of AND-expressions get the mark_as_condition_AND_part() call - Item_in_subselect objects record that they are AND-parts of WHERE/ON
-
- 23 Aug, 2011 1 commit
-
-
unknown authored
Analysis: During the first execution of the query through the stored procedure, the optimization phase calls substitute_for_best_equal_field(), which calls Item_in_optimizer::transform(). The latter replaces Item_in_subselect::left_expr with args[0] via assignment. In this test case args[0] is an Item_outer_ref which is created/deallocated for each re-execution. As a result, during the second execution Item_in_subselect::left_expr pointed to freed memory, which resulted in a crash. Solution: The solution is to use change_item_tree(), so that the origianal left expression is restored after each execution.
-
- 19 Aug, 2011 1 commit
-
-
Tor Didriksen authored
Bug#12532830 - SIGFPE OR ASSERTION (PRECISION <= ((9 * 9) - 8*2)) && (DEC <= 30)
-
- 17 Aug, 2011 1 commit
-
-
unknown authored
The bug is a duplicate of MySQL's Bug#11764086, however MySQL's fix is incomplete for MariaDB, so this fix is slightly different. In addition, this patch renames Item_func_not_all::top_level() to is_top_level_item() to make it in line with the analogous methods of Item_in_optimizer, and Item_subselect. Analysis: It is possible to determine whether a predicate is NULL-rejecting only if it is a top-level one. However, this was not taken into account for Item_in_optimizer. As a result, a NOT IN predicate was erroneously considered as NULL-rejecting, and the NULL-complemented rows generated by the outer join were rejected before being checked by the NOT IN predicate. Solution: Change Item_in_optimizer to be considered as NULL-rejecting only if it a top-level predicate.
-
- 20 Jul, 2011 1 commit
-
-
unknown authored
ALL subquery should return TRUE if subquery rowa set is empty independently of left part. The problem was that Item_func_(eq,ne,gt,ge,lt,le) do not call execution of second argument if first is NULL no in this case subquery will not be executed and when Item_func_not_all calls any_value() of the subquery or aggregation function which report that there was rows. So for NULL < ALL (SELECT...) result was FALSE instead of TRUE. Fix is just swapping of arguments of Item_func_(eq,ne,gt,ge,lt,le) (with changing the operation if it is needed) so that result will be the same (for examole a < b is equal to b > a). This fix exploit the fact that first argument will be executed in any case. mysql-test/r/subselect.result: The test suite added. mysql-test/r/subselect_no_mat.result: The test suite added. mysql-test/r/subselect_no_opts.result: The test suite added. mysql-test/r/subselect_no_semijoin.result: The test suite added. mysql-test/r/subselect_scache.result: The test suite added. mysql-test/t/subselect.test: The test suite added. sql/item_cmpfunc.cc: Swap arguments creation methods added. sql/item_cmpfunc.h: Swap arguments creation methods added. sql/item_subselect.cc: Swap arguments of the comparison.
-