An error occurred fetching the project authors.
- 12 Jul, 2007 1 commit
-
-
igor@olga.mysql.com authored
A bug in the restore_prev_nj_state function allowed interleaving inner tables of outer join operations with outer tables. With the current implementation of the nested loops algorithm it could lead to wrong result sets for queries with nested outer joins. Another bug in this procedure effectively blocked evaluation of some valid execution plans for queries with nested outer joins.
-
- 29 Jun, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
query / no aggregate of subquery The optimizer counts the aggregate functions that appear as top level expressions (in all_fields) in the current subquery. Later it makes a list of these that it uses to actually execute the aggregates in end_send_group(). That count is used in several places as a flag whether there are aggregates functions. While collecting the above info it must not consider aggregates that are not aggregated in the current context. It must treat them as normal expressions instead. Not doing that leads to incorrect data about the query, e.g. running a query that actually has no aggregate functions as if it has some (and hence is expected to return only one row). Fixed by ignoring the aggregates that are not aggregated in the current context. One other smaller omission discovered and fixed in the process : the place of aggregation was not calculated for user defined functions. Fixed by calling Item_sum::init_sum_func_check() and Item_sum::check_sum_func() as it's done for the rest of the aggregate functions.
-
- 24 Jun, 2007 1 commit
-
-
igor@olga.mysql.com authored
the loose scan optimization for grouping queries was applied returned a wrong result set when the query was used with the SQL_BIG_RESULT option. The SQL_BIG_RESULT option forces to use sorting algorithm for grouping queries instead of employing a suitable index. The current loose scan optimization is applied only for one table queries when the suitable index is covering. It does not make sense to use sort algorithm in this case. However the create_sort_index function does not take into account the possible choice of the loose scan to implement the DISTINCT operator which makes sorting unnecessary. Moreover the current implementation of the loose scan for queries with distinct assumes that sorting will never happen. Thus in this case create_sort_index should not call the function filesort.
-
- 23 Jun, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
INSERT into table from SELECT from the same table with ORDER BY and LIMIT was inserting other data than sole SELECT ... ORDER BY ... LIMIT returns. One part of the patch for bug #9676 improperly pushed LIMIT to temporary table in the presence of the ORDER BY clause. That part has been removed.
-
- 20 Jun, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
For a join query with GROUP BY and/or ORDER BY and a view reference in the FROM list the metadata erroneously showed empty table aliases and database names for the view columns.
-
- 18 Jun, 2007 1 commit
-
-
mhansson/martin@linux-st28.site authored
The method select_insert::send_error does two things, it rolls back a statement being executed and outputs an error message. But when a nonexistent column is referenced, an error message has been published already and there is no need to publish another. Fixed by moving all functionality beyond publishing an error message into select_insert::abort() and calling only that function.
-
- 11 Jun, 2007 1 commit
-
-
kaa@polly.local authored
In create_tmp_table() don't set full table path as a table name. Other code assumes table names to not exceed NAME_LEN bytes.
-
- 07 Jun, 2007 1 commit
-
-
igor@olga.mysql.com authored
a temporary table has grown out of heap memory reserved for it and the remaining disk space is not big enough to store the table as a MyISAM table. The crash happens because the function create_myisam_from_heap does not handle safely the mem_root structure associated with the converted table in the case when an error has occurred.
-
- 02 Jun, 2007 1 commit
-
-
igor@olga.mysql.com authored
using a derived table over a grouping subselect. This crash happens only when materialization of the derived tables requires creation of auxiliary temporary table, for example when a grouping operation is carried out with usage of a temporary table. The crash happened because EXPLAIN EXTENDED when printing the query expression made an attempt to use the objects created in the mem_root of the temporary table which has been already freed by the moment when printing is called. This bug appeared after the method Item_field::print() had been introduced.
-
- 31 May, 2007 2 commits
-
-
kaa@polly.local authored
Problem: HASH indexes on VARCHAR columns with binary collations did not ignore trailing spaces from strings before comparisons. This could result in duplicate records being successfully inserted into a MEMORY table with unique key constraints. As a direct consequence of the above, internal MEMORY tables used for GROUP BY calculation in testcases for bug #27643 contained duplicate rows which resulted in duplicate key errors when converting those temporary tables to MyISAM. Additionally, that error was incorrectly converted to the 'table is full' error. Solution: - ignore trailing spaces in VARCHAR fields with binary collations when calculating hashes. - return a proper error from create_myisam_from_heap() when conversion fails.
-
gshchepa/uchum@gleb.loc authored
mysqld crashed when a long-running explain query was killed from another connection. When the current thread caught a kill signal executing the function best_extension_by_limited_search it just silently returned to the calling function greedy_search without initializing elements of the join->best_positions array. However, the greedy_search function ignored thd->killed status after a calls to the best_extension_by_limited_search function, and after several calls the greedy_search function used an uninitialized data from the join->best_positions[idx] to search position in the join->best_ref array. That search failed, and greedy_search tried to call swap_variables function with NULL argument - that caused a crash.
-
- 30 May, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
Integer values with 10 digits may or may not fit into an int column (e.g. 2147483647 vs 6147483647). Thus when creating a temp table column for such an int we must use bigint instead. Fixed to use bigint. Also subsituted a "magic number" with a named constant.
-
- 26 May, 2007 2 commits
-
-
igor@olga.mysql.com authored
-
igor@olga.mysql.com authored
constant outer tables did not return null complemented rows when conditions were evaluated to FALSE. Wrong results were returned because the conditions over constant outer tables, when being pushed down, were erroneously enclosed into the guard function used for WHERE conditions.
-
- 24 May, 2007 1 commit
-
-
igor@olga.mysql.com authored
CHECK OPTION and a subquery in WHERE condition. The abort was triggered by setting the value of join->tables for subqueries in the function JOIN::cleanup. This function was called after an invocation of the JOIN::join_free method for subqueries used in WHERE condition.
-
- 22 May, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
When processing the USE/FORCE index hints the optimizer was not checking if the indexes specified are enabled (see ALTER TABLE). Fixed by: Backporting the fix for bug 20604 to 5.0
-
- 21 May, 2007 1 commit
-
-
mhansson@dl145s.mysql.com authored
-
- 15 May, 2007 1 commit
-
-
igor@olga.mysql.com authored
for a query over an empty table right after its creation. The crash is the result of an attempt made by JOIN::optimize to evaluate the WHERE condition when no records have been actually read. The added test case can reproduce the crash only with InnoDB tables and only with 5.0.x.
-
- 10 May, 2007 1 commit
-
-
igor@olga.mysql.com authored
ref access to a less expensive range access. This occurred only with InnoDB tables.
-
- 04 May, 2007 3 commits
-
-
gkodinov/kgeorge@magare.gmz authored
fixed coverage of out-of-mem errors
-
gkodinov/kgeorge@magare.gmz authored
When checking for applicability of join cache we must disable its usage only if there is no temp table in use. When a temp table is used we can use join cache (and it will not make the result-set unordered) to fill the temp table. The filesort() operation is then applied to the data in the temp table and hence is not affected by join cache usage. Fixed by narrowing the condition for disabling join cache to exclude the case where temp table is used.
-
gkodinov/kgeorge@magare.gmz authored
Non-correlated scalar subqueries may get executed in EXPLAIN at the optimization phase if they are part of a right hand sargable expression. If the scalar subquery uses a temp table to materialize its results it will replace the subquery structure from the parser with a simple select from the materialization table. As a result the EXPLAIN will crash as the temporary materialization table is not to be shown in EXPLAIN at all. Fixed by preserving the original query structure right after calling optimize() for scalar subqueries with temp tables executed during EXPLAIN.
-
- 02 May, 2007 1 commit
-
-
igor@olga.mysql.com authored
'not exists' optimization is applied. In fact 'not exists' optimization did not work anymore after the patch introducing the evaluate_join_record function had been applied. Corrected the evaluate_join_record function to respect the 'not_exists' optimization.
-
- 30 Apr, 2007 1 commit
-
-
igor@olga.mysql.com authored
-
- 29 Apr, 2007 1 commit
-
-
igor@olga.mysql.com authored
some rollup rows (rows with NULLs for grouping attributes) if GROUP BY list contained constant expressions. This happened because the results of constant expressions were not put in the temporary table used for duplicate elimination. In fact a constant item from the GROUP BY list of a ROLLUP query can be replaced for an Item_null_result object when a rollup row is produced . Now the JOIN::rollup_init function wraps any constant item referenced in the GROYP BY list of a ROLLUP query into an Item_func object of a special class that is never detected as constant item. This ensures creation of fields for such constant items in temporary tables and guarantees right results when the result of the rollup operation first has to be written into a temporary table, e.g. in the cases when duplicate elimination is required.
-
- 26 Apr, 2007 1 commit
-
-
evgen@moonbone.local authored
DATE and DATETIME can be compared either as strings or as int. Both methods have their disadvantages. Strings can contain valid DATETIME value but have insignificant zeros omitted thus became non-comparable with other DATETIME strings. The comparison as int usually will require conversion from the string representation and the automatic conversion in most cases is carried out in a wrong way thus producing wrong comparison result. Another problem occurs when one tries to compare DATE field with a DATETIME constant. The constant is converted to DATE losing its precision i.e. losing time part. This fix addresses the problems described above by adding a special DATE/DATETIME comparator. The comparator correctly converts DATE/DATETIME string values to int when it's necessary, adds zero time part (00:00:00) to DATE values to compare them correctly to DATETIME values. Due to correct conversion malformed DATETIME string values are correctly compared to other DATE/DATETIME values. As of this patch a DATE value equals to DATETIME value with zero time part. For example '2001-01-01' equals to '2001-01-01 00:00:00'. The compare_datetime() function is added to the Arg_comparator class. It implements the correct comparator for DATE/DATETIME values. Two supplementary functions called get_date_from_str() and get_datetime_value() are added. The first one extracts DATE/DATETIME value from a string and the second one retrieves the correct DATE/DATETIME value from an item. The new Arg_comparator::can_compare_as_dates() function is added and used to check whether two given items can be compared by the compare_datetime() comparator. Two caching variables were added to the Arg_comparator class to speedup the DATE/DATETIME comparison. One more store() method was added to the Item_cache_int class to cache int values. The new is_datetime() function was added to the Item class. It indicates whether the item returns a DATE/DATETIME value.
-
- 20 Apr, 2007 1 commit
-
-
mhansson@dl145s.mysql.com authored
This bug was intruduced by the fix for bug#17212 (in 4.1). It is not ok to call test_if_skip_sort_order since this function will alter the execution plan. By contract it is not ok to call test_if_skip_sort_order in this context. This bug appears only in the case when the optimizer has chosen an index for accessing a particular table but finds a covering index that enables it to skip ORDER BY. This happens in test_if_skip_sort_order.
-
- 18 Apr, 2007 1 commit
-
-
sergefp@mysql.com authored
- Turn it on for JT_EQ_REF access method
-
- 15 Apr, 2007 1 commit
-
-
evgen@moonbone.local authored
The Item_outer_ref class based on the Item_direct_ref class was always used to represent an outer field. But if the outer select is a grouping one and the outer field isn't under an aggregate function which is aggregated in that outer select an Item_ref object should be used to represent such a field. If the outer select in which the outer field is resolved isn't grouping then the Item_field class should be used to represent such a field. This logic also should be used for an outer field resolved through its alias name. Now the Item_field::fix_outer_field() uses Item_outer_field objects to represent aliased and non-aliased outer fields for grouping outer selects only. Now the fix_inner_refs() function chooses which class to use to access outer field - the Item_ref or the Item_direct_ref. An object of the chosen class substitutes the original field in the Item_outer_ref object. The direct_ref and the found_in_select_list fields were added to the Item_outer_ref class.
-
- 10 Apr, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
The optimizer transforms DISTINCT into a GROUP BY when possible. It does that by constructing the same structure (a list of ORDER instances) the parser makes when parsing GROUP BY. While doing that it also eliminates duplicates. But if a duplicate is found it doesn't advance the pointer to ref_pointer array, so the next (and subsequent) ORDER structures point to the wrong element in the SELECT list. Fixed by advancing the pointer in ref_pointer_array even in the case of a duplicate.
-
- 31 Mar, 2007 1 commit
-
-
igor@olga.mysql.com authored
conditions. When allocating memory for KEY_FIELD/SARGABLE_PARAM structures the function update_ref_and_keys did not take into account the fact that a single row equality could be replaced by several simple equalities. Fixed by adjusting the counter cond_count accordingly for each subquery when performing substitution of a row equality for simple equalities.
-
- 29 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
When creating a temporary table the concise column type of a string expression is decided based on its length: - if its length is under 512 it is stored as either varchar or char. - otherwise it is stored as a BLOB. There is a flag (convert_blob_length) to create_tmp_field that, when >0 allows to force creation of a varchar if the max blob length is under convert_blob_length. However it must be verified that convert_blob_length (settable through a SQL option in some cases) is under the maximum that can be stored in a varchar column. While performing that check for expressions in create_tmp_field_from_item the max length of the blob was used instead. This causes blob columns to be created in the heap temp table used by GROUP_CONCAT (where blobs must not be created in the temp table because of the constant convert_blob_length that is passed to create_tmp_field() ). And since these blob columns are not expected in that place we get wrong results. Fixed by checking that the value of the flag variable is in the limits that fit into VARCHAR instead of the max length of the blob column.
-
- 28 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
Geometry fields have a result type string and a special subclass to cater for the differences between them and the base class (just like DATE/TIME). When creating temporary tables for results of functions that return results of type GEOMETRY we must construct fields of the derived class instead of the base class. Fixed by creating a GEOMETRY field (Field_geom) instead of a generic BLOB (Field_blob) in temp tables for the results of GIS functions that have GEOMETRY return type (Item_geometry_func).
-
- 27 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
When creating a temporary table the concise column type of a string expression is decided based on its length: - if its length is under 512 it is stored as either varchar or char. - otherwise it is stored as a BLOB. There is a flag (convert_blob_length) to create_tmp_field that, when >0 allows to force creation of a varchar if the max blob length is under convert_blob_length. However it must be verified that convert_blob_length (settable through a SQL option in some cases) is under the maximum that can be stored in a varchar column. While performing that check for expressions in create_tmp_field_from_item the max length of the blob was used instead. This causes blob columns to be created in the heap temp table used by GROUP_CONCAT (where blobs must not be created in the temp table because of the constant convert_blob_length that is passed to create_tmp_field() ). And since these blob columns are not expected in that place we get wrong results. Fixed by checking that the value of the flag variable is in the limits that fit into VARCHAR instead of the max length of the blob column.
-
- 26 Mar, 2007 1 commit
-
-
igor@olga.mysql.com authored
from func_group.test after the patch for bug #27229 had been applied. The memory corruption happened because in some rare cases the function count_field_types underestimated the number of elements in in the array param->items_to_copy.
-
- 22 Mar, 2007 3 commits
-
-
igor@olga.mysql.com authored
context was used as an argument of GROUP_CONCAT. Ensured correct setting of the depended_from field in references generated for set functions aggregated in outer selects. A wrong value of this field resulted in wrong maps returned by used_tables() for these references. Made sure that a temporary table field is added for any set function aggregated in outer context when creation of a temporary table is needed to execute the inner subquery.
-
jani@ua141d10.elisa.omakaista.fi authored
-
guilhem@gbichot3.local authored
what it actually means (Monty approved the renaming) - correcting description of transaction_alloc command-line options (our manual is correct) - fix for a failure of rpl_trigger.
-
- 20 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.local authored
To correctly decide which predicates can be evaluated with a given table the optimizer must know the exact set of tables that a predicate depends on. If that mask is too wide (refer to non-existing tables) the optimizer can erroneously skip a predicate. One such case of wrong table usage mask were the aggregate functions. The have a all-1 mask (meaning depend on all tables, including non-existent ones). Fixed by making a real used_tables mask for the aggregates. The mask is constructed in the following way : 1. OR the table dependency masks of all the arguments of the aggregate. 2. If all the arguments of the function are from the local name resolution context and it is evaluated in the same name resolution context where it is referenced all the tables from that name resolution context are OR-ed to the dependency mask. This is to denote that an aggregate function depends on the number of rows it processes. 3. Handle correctly the case of an aggregate function optimization (such that the aggregate function can be pre-calculated and made a constant). Made sure that an aggregate function is never a constant (unless subject of a specific optimization and pre-calculation). One other flaw was revealed and fixed in the process : references were not calling the recalculation method for used_tables of their targets.
-
- 09 Mar, 2007 1 commit
-
-
anozdrin/alik@booka.opbmk authored
-