An error occurred fetching the project authors.
  1. 17 Aug, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#30245: A wrong type of a BIT field is reported when grouped by it. · 9a83ddda
      evgen@moonbone.local authored
      HEAP tables can't index BIT fields. Due to this when grouping by such fields is
      needed they are converted to a fields of the LONG type when temporary table
      is being created. But a side effect of this is that a wrong type of BIT
      fields is returned to a client.
      
      Now the JOIN::prepare and the create_distinct_group functions are create
      additional hidden copy of BIT fields to preserve original fields untouched.
      New hidden fields are used for grouping instead.
      9a83ddda
  2. 31 Jul, 2007 2 commits
    • sergefp@mysql.com's avatar
      BUG#29582: huge memory consumption with union, subselect, joins: · c37f9b9e
      sergefp@mysql.com authored
      - Don't call mysql_select() several times for the select that enumerates
        a temporary table with the results of the UNION. Making this call for
        every subquery execution caused O(#enumerated-rows-in-the-outer-query) 
        memory allocations.
      - Instead, call join->reinit() and join->exec(), and
        = disable constant table detection for such joins,  
        = provide special handling for table-less constant subqueries.
      c37f9b9e
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Bug #29717 INSERT INTO SELECT inserts values even if · f1ee2d06
      holyfoot/hf@mysql.com/hfmain.(none) authored
       SELECT statement itself returns empty.
      
      As a result of this bug 'SELECT AGGREGATE_FUNCTION(fld) ... GROUP BY'
      can return one row instead of an empty result set.
      
      When GROUP BY only has fields of constant tables
      (with a single row), the optimizer deletes the group_list.
      After that we lose the information about whether we had an
      GROUP BY statement. Though it's important
      as SELECT min(x) from empty_table; and
         SELECT min(x) from empty_table GROUP BY y; have to return
      different results - the first query should return one row,
      second - an empty result set.
      So here we add the 'group_optimized_away' flag to remember this case
      when GROUP BY exists in the query and is removed
      by the optimizer, and check this flag in end_send_group()
      f1ee2d06
  3. 26 Jul, 2007 1 commit
  4. 23 Jul, 2007 1 commit
  5. 21 Jul, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #29911. · 07e0cd2f
      igor@olga.mysql.com authored
      This bug manifested itself for join queries with GROUP BY and HAVING clauses
      whose SELECT lists contained DISTINCT. It occurred when the optimizer could
      deduce that the result set would have not more than one row.
      The bug could lead to wrong result sets for queries of this type because
      HAVING conditions were erroneously ignored in some cases in the function
      remove_duplicates.   
      07e0cd2f
  6. 20 Jul, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #28591: MySQL need not sort the records in case of · 8fc401e2
      gkodinov/kgeorge@magare.gmz authored
      ORDER BY primary_key on InnoDB table
      
      Queries that use an InnoDB secondary index to retrieve
      data don't need to sort in case of ORDER BY primary key
      if the secondary index is compared to constant(s).
      They can also skip sorting if ORDER BY contains both the
      the secondary key parts and the primary key parts (in
      that order).
      This is because InnoDB returns the rows in order of the
      primary key for rows with the same values of the secondary
      key columns.
      Fixed by preventing temp table sort for the qualifying 
      queries.
      8fc401e2
  7. 12 Jul, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #29604. · 7f64144b
      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. 
      7f64144b
  8. 06 Jul, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      Remove typedef st_table_list TABLE_LIST and always use name 'TABLE_LIST'. · a33bc2c2
      kostja@bodhi.(none) authored
      The need arose when working on Bug 26141, where it became
      necessary to replace TABLE_LIST with its forward declaration in a few
      headers, and this involved a lot of s/TABLE_LIST/st_table_list/.
      Although other workarounds exist, this patch is in line
      with our general strategy of moving away from typedef-ed names.
      Sometime in future we might also rename TABLE_LIST to follow the
      coding style, but this is a huge change.
      a33bc2c2
  9. 29 Jun, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug#27333: subquery grouped for aggregate of outer · 38172240
      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.
      38172240
  10. 24 Jun, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #25602. A query with DISTINCT in the select list to which · 59b9077c
      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.
      59b9077c
  11. 23 Jun, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #29095. · fbbb30a6
      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.
      fbbb30a6
  12. 20 Jun, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #28898. · 2379f977
      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.
      2379f977
  13. 18 Jun, 2007 1 commit
    • mhansson/martin@linux-st28.site's avatar
      Bug#28677: SELECT on missing column gives extra error · cc2d534a
      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.
      cc2d534a
  14. 11 Jun, 2007 1 commit
  15. 07 Jun, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #28449: a crash may happen at some rare conditions when · 56996041
      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.
      56996041
  16. 02 Jun, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #28728: a crash when executing EXPLAIN EXTENDED for a query · 5cbebf0a
      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.    
      5cbebf0a
  17. 31 May, 2007 2 commits
    • kaa@polly.local's avatar
      Fix for bug #27643 "query failed : 1114 (The table '' is full) · d435b3ed
      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.
      d435b3ed
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #28598. · e16953df
      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.
      e16953df
  18. 30 May, 2007 1 commit
  19. 26 May, 2007 2 commits
  20. 24 May, 2007 1 commit
  21. 22 May, 2007 1 commit
  22. 21 May, 2007 1 commit
  23. 15 May, 2007 1 commit
  24. 10 May, 2007 1 commit
  25. 04 May, 2007 3 commits
    • gkodinov/kgeorge@magare.gmz's avatar
      bug #27531: · 13e55b8a
      gkodinov/kgeorge@magare.gmz authored
       fixed coverage of out-of-mem errors
      13e55b8a
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #27531: the 4.1 fix. · d11e1f24
      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.
      d11e1f24
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #27807. · 6badb08c
      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.
      6badb08c
  26. 02 May, 2007 1 commit
  27. 30 Apr, 2007 1 commit
  28. 29 Apr, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #24856: the result set of a ROLLUP query with DISTINCT could lack · ce0be732
      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.  
      ce0be732
  29. 26 Apr, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#27590: Wrong DATE/DATETIME comparison. · 4747fa0c
      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.
      4747fa0c
  30. 20 Apr, 2007 1 commit
    • mhansson@dl145s.mysql.com's avatar
      Bug #24778: Innodb: No result when using ORDER BY · f0fc4b88
      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.
      f0fc4b88
  31. 18 Apr, 2007 1 commit
  32. 15 Apr, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#27321: Wrong subquery result in a grouping select. · 3113ce63
      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.
      3113ce63
  33. 10 Apr, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #27659: · aefc060f
      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.
      aefc060f
  34. 31 Mar, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #27154: memory corruption when using row equalities in where · 0c5ba624
      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. 
       
      0c5ba624
  35. 29 Mar, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #26815: · c52e8b3e
      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.
      c52e8b3e