An error occurred fetching the project authors.
  1. 09 Dec, 2008 1 commit
  2. 24 Nov, 2008 1 commit
  3. 17 Oct, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug #33811: Call to stored procedure with SELECT * / RIGHT JOIN · a0e3001c
      Georgi Kodinov authored
      fails after the first time
        
      Two separate problems : 
        1. When flattening joins the linked list used for name resolution 
        (next_name_resolution_table) was not updated.
        Fixed by updating the pointers when extending the table list
        
        2. The items created by expanding a * (star) as a column reference
        were marked as fixed, but no cached table was assigned to them 
        (unlike what Item_field::fix_fields does).
        Fixed by assigning a cached table (so the re-preparation is done
        faster).
        
      Note that the fix for #2 hides the fix for #1 in most cases
      (except when a table reference cannot be cached).
      a0e3001c
  4. 16 Oct, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #39844: Query Crash Mysql Server 5.0.67 · c411a11e
      Gleb Shchepa authored
      Server crashed during a sort order optimization
      of a dependent subquery:
      
      SELECT
          (SELECT t1.a FROM t1, t2
            WHERE t1.a = t2.b AND t2.a = t3.c
            ORDER BY t1.a)
        FROM t3;
      
      
      Bitmap of tables, that the reference to outer table
      column uses, in addition to the regular table bit
      has the OUTER_REF_TABLE_BIT bit set.
      The only_eq_ref_tables function traverses this map
      bit by bit simultaneously with join->map2table list.
      Obviously join->map2table never contains an entry
      for the OUTER_REF_TABLE_BIT pseudo-table, so the
      server crashed there.
      
      
      The only_eq_ref_tables function has been modified
      to traverse regular table bits only like the
      update_depend_map function (resetting of the
      OUTER_REF_TABLE_BIT there is enough, but
      resetting of the whole set of PSEUDO_TABLE_BITS
      is used there for sure).
      c411a11e
  5. 10 Oct, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #39283: Date returned as VARBINARY to client for queries · e7520c4b
      Gleb Shchepa authored
                  with COALESCE and JOIN
      
      The server returned to a client the VARBINARY column type
      instead of the DATE type for a result of the COALESCE,
      IFNULL, IF, CASE, GREATEST or LEAST functions if that result
      was filesorted in an anonymous temporary table during
      the query execution.
      
      For example:
        SELECT COALESCE(t1.date1, t2.date2) AS result
          FROM t1 JOIN t2 ON t1.id = t2.id ORDER BY result;
      
      
      To create a column of various date/time types in a
      temporary table the create_tmp_field_from_item() function
      uses the Item::tmp_table_field_from_field_type() method
      call. However, fields of the MYSQL_TYPE_NEWDATE type were
      missed there, and the VARBINARY columns were created
      by default.
      Necessary condition has been added.
      e7520c4b
  6. 06 Oct, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug#34773: query with explain extended and derived table / other table · b5f152dc
      Georgi Kodinov authored
      crashes server
      
      When creating temporary table that contains aggregate functions a 
      non-reversible source transformation was performed to redirect aggregate
      function arguments towards temporary table columns.
      This caused EXPLAIN EXTENDED to fail because it was trying to resolve
      references to the (freed) temporary table.
      Fixed by preserving the original aggregate function arguments and
      using them (instead of the transformed ones) for EXPLAIN EXTENDED.
      b5f152dc
  7. 02 Oct, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug #37348: Crash in or immediately after JOIN::make_sum_func_list · 452fed70
      Georgi Kodinov authored
            
      The optimizer pulls up aggregate functions which should be aggregated in
      an outer select. At some point it may substitute such a function for a field
      in the temporary table. The setup_copy_fields function doesn't take this
      into account and may overrun the copy_field buffer.
            
      Fixed by filtering out the fields referenced through the specialized
      reference for aggregates (Item_aggregate_ref).
      Added an assertion to make sure bugs that cause similar discrepancy 
      don't go undetected.
      452fed70
  8. 27 Aug, 2008 2 commits
    • Georgi Kodinov's avatar
      Bug#37548: result value erronously reported being NULL in certain subqueries · 3468f4b4
      Georgi Kodinov authored
            
      When switching to indexed ORDER BY we must be sure to reset the index read
      flag if we are switching from a covering index to non-covering.
      3468f4b4
    • Evgeny Potemkin's avatar
      Bug#38195: Incorrect handling of aggregate functions when loose index scan is · 1f28ee88
      Evgeny Potemkin authored
      used causes server crash.
            
      When the loose index scan access method is used values of aggregated functions
      are precomputed by it. Aggregation of such functions shouldn't be performed
      in this case and functions should be treated as normal ones.
      The create_tmp_table function wasn't taking this into account and this led to
      a crash if a query has MIN/MAX aggregate functions and employs temporary table
      and loose index scan.
      Now the JOIN::exec and the create_tmp_table functions treat MIN/MAX aggregate
      functions as normal ones when the loose index scan is used.
      1f28ee88
  9. 19 Aug, 2008 1 commit
  10. 13 Aug, 2008 1 commit
    • Evgeny Potemkin's avatar
      Bug#38195: Incorrect handling of aggregate functions when loose index scan is · cf28ff26
      Evgeny Potemkin authored
      used causes server crash.
      
      When the loose index scan access method is used values of aggregated functions
      are precomputed by it. Aggregation of such functions shouldn't be performed
      in this case and functions should be treated as normal ones.
      The create_tmp_table function wasn't taking this into account and this led to
      a crash if a query has MIN/MAX aggregate functions and employs temporary table
      and loose index scan.
      Now the JOIN::exec and the create_tmp_table functions treat MIN/MAX aggregate
      functions as normal ones when the loose index scan is used.
      cf28ff26
  11. 26 Jul, 2008 1 commit
    • Igor Babaev's avatar
      Fixed bug #38191. · da156dde
      Igor Babaev authored
      Calling List<Cached_item>::delete_elements for the same list twice
      caused a crash of the server in the function JOIN::cleaunup.
      Ensured that delete_elements() in JOIN::cleanup would be called only once.
      da156dde
  12. 23 Jul, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug#37830 : ORDER BY ASC/DESC - no difference · 436f1dc4
      Georgi Kodinov authored
                        
      Range scan in descending order for c <= <col> <= c type of
      ranges was ignoring the DESC flag.
      However some engines like InnoDB have the primary key parts 
      as a suffix for every secondary key.
      When such primary key suffix is used for ordering ignoring 
      the DESC is not valid.
      But we generally would like to do this because it's faster.
                  
      Fixed by performing only reverse scan if the primary key is used.
      Removed some dead code in the process.
      436f1dc4
  13. 16 Jul, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug#37830 : ORDER BY ASC/DESC - no difference · 59ab9a08
      Georgi Kodinov authored
                  
      Range scan in descending order for c <= <col> <= c type of
      ranges was ignoring the DESC flag.
      However some engines like InnoDB have the primary key parts 
      as a suffix for every secondary key.
      When such primary key suffix is used for ordering ignoring 
      the DESC is not valid.
      But we generally would like to do this because it's faster.
            
      Fixed by performing only reverse scan if the primary key is used.
      Removed some dead code in the process.
      59ab9a08
  14. 15 Jul, 2008 1 commit
    • Sergey Petrunia's avatar
      BUG#35478: sort_union() returns bad data when sort_buffer_size is hit · 2951f00b
      Sergey Petrunia authored
      - In QUICK_INDEX_MERGE_SELECT::read_keys_and_merge: when we got table->sort from Unique,
        tell init_read_record() not to use rr_from_cache() because a) rowids are already sorted
        and b) it might be that the the data is used by filesort(), which will need record rowids
        (which rr_from_cache() cannot provide).
      - Fully de-initialize the table->sort read in QUICK_INDEX_MERGE_SELECT::get_next(). This fixes BUG#35477.
      (bk trigger: file as fix for BUG#35478).
      2951f00b
  15. 27 Jun, 2008 1 commit
    • Gleb Shchepa's avatar
      Fixed bug #36632: SELECT DISTINCT from a simple view on an · fc827ae3
      Gleb Shchepa authored
                        InnoDB table, where all selected columns
                        belong to the same unique index key, returns
                        incorrect results
      
      Server executes some queries via QUICK_GROUP_MIN_MAX_SELECT
      (MIN/MAX optimization for queries with GROUP BY or DISTINCT
      clause) and that optimization implies loose index scan, so all
      grouping is done by the QUICK_GROUP_MIN_MAX_SELECT::get_next
      method.
      
      The server does not set the precomputed_group_by flag for some
      QUICK_GROUP_MIN_MAX_SELECT queries and duplicates grouping by
      call to the end_send_group function.
      
      Fix: when the test_if_skip_sort_order function selects loose 
      index scan as a best way to satisfy an ORDER BY/GROUP BY type
      of query, the precomputed_group_by flag has been set to use 
      end_send/end_write functions instead of end_send_group/
      end_write_group functions.
      fc827ae3
  16. 19 Jun, 2008 1 commit
  17. 16 May, 2008 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #36011: server crash with explain extended on query · df3341a7
      gkodinov/kgeorge@magare.gmz authored
         with dependent subqueries
      An IN subquery is executed on EXPLAIN when it's not correlated.
      If the subquery required a temporary table for its execution
      not all the internal structures were restored from pointing to
      the items of the temporary table to point back to the items of
      the subquery.
      Fixed by restoring the ref array when a temp tables were used in
      executing the IN subquery during EXPLAIN EXTENDED.
      df3341a7
  18. 07 May, 2008 1 commit
  19. 23 Apr, 2008 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug#35844. · b210e5df
      igor@olga.mysql.com authored
      The function test_if_skip_sort_order ignored any covering index used for ref
      access of a table in a query with ORDER BY if this index was incompatible 
      with the ORDER BY list and there was another covering index compatible with
      this list. 
      As a result sub-optimal execution plans were chosen for some queries with
      ORDER BY clause. 
      b210e5df
  20. 22 Apr, 2008 1 commit
  21. 28 Mar, 2008 1 commit
  22. 27 Mar, 2008 2 commits
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #35206: select query result different if the key is indexed or not · cde380ea
      gkodinov/kgeorge@magare.gmz authored
      The code for executing indexed ORDER BY was not setting all the 
      internal fields correctly when selecting to execute ORDER BY over
      and index.
      Fixed by change the access method to one that will use the 
      quick indexed access if one is selected while selecting indexed
      ORDER BY.
      cde380ea
    • evgen@moonbone.local's avatar
      Bug#27219: Aggregate functions in ORDER BY. · 21c6145a
      evgen@moonbone.local authored
      Mixing aggregate functions and non-grouping columns is not allowed in the
      ONLY_FULL_GROUP_BY mode. However in some cases the error wasn't thrown because
      of insufficient check.
      
      In order to check more thoroughly the new algorithm employs a list of outer
      fields used in a sum function and a SELECT_LEX::full_group_by_flag.
      Each non-outer field checked to find out whether it's aggregated or not and
      the current select is marked accordingly.
      All outer fields that are used under an aggregate function are added to the
      Item_sum::outer_fields list and later checked by the Item_sum::check_sum_func
      function.
      21c6145a
  23. 26 Mar, 2008 2 commits
    • gshchepa/uchum@host.loc's avatar
      Fixed bug #35193. · 2dcec449
      gshchepa/uchum@host.loc authored
      View definition as SELECT ... FROM DUAL WHERE ... has
      valid syntax, but use of such view in SELECT or
      SHOW CREATE VIEW syntax causes unexpected syntax error.
      
      Server omits FROM DUAL clause when storing view body
      string in a .frm file for further evaluation.
      However, syntax of SELECT-witout-FROM query is more
      restrictive than SELECT FROM DUAL syntax, and doesn't
      allow the WHERE clause.
      
      NOTE: this syntax difference is not documented.
      
      
      View registration procedure has been modified to
      preserve original structure of view's body.
      2dcec449
    • kaa@kaamos.(none)'s avatar
      Fix for bug #34928: Confusion by having Primary Key and Index · b753e4a0
      kaa@kaamos.(none) authored
      The bug is a regression introduced in 5.1 by the patch for bug28404.
      
      Under some circumstances test_if_skip_sort_order() could leave some
      data structures in an inconsistent state so that some parts of code
      could assume the selected execution strategy for GROUP BY/DISTINCT as
      a loose index scan (e.g. JOIN_TAB::is_using_loose_index_scan()), while
      the actual strategy chosen was an ordered index scan, which led to
      wrong data being returned.
      
      Fixed test_if_skip_sort_order() so that when changing the type for a
      join table, select->quick is reset not only for EXPLAIN, but for the 
      actual join execution as well, to not confuse code that depends on its
      value to determine the chosen GROUP BY/DISTINCT strategy.
      b753e4a0
  24. 03 Mar, 2008 1 commit
  25. 29 Feb, 2008 1 commit
  26. 22 Feb, 2008 1 commit
    • anozdrin/alik@quad.'s avatar
      Fix for Bug#30217: Views: changes in metadata behaviour · 340906f4
      anozdrin/alik@quad. authored
      between 5.0 and 5.1.
        
      The problem was that in the patch for Bug#11986 it was decided
      to store original query in UTF8 encoding for the INFORMATION_SCHEMA.
      This approach however turned out to be quite difficult to implement
      properly. The main problem is to preserve the same IS-output after
      dump/restore.
        
      So, the fix is to rollback to the previous functionality, but also
      to fix it to support multi-character-set-queries properly. The idea
      is to generate INFORMATION_SCHEMA-query from the item-tree after
      parsing view declaration. The IS-query should:
        - be completely in UTF8;
        - not contain character set introducers.
        
      For more information, see WL4052.
      340906f4
  27. 17 Feb, 2008 1 commit
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Bug #32942 now() - interval '7200' second NOT pre-calculated, causing "full table scan" · 7abba3b0
      holyfoot/hf@mysql.com/hfmain.(none) authored
      Problem is not about intervals and doesn't actually cause 'full table scan'.
      We have an optimization for DISTINCT when we have
      'DISTINCT field_from_first_join_table' we don't need to read all the
      rows from the JOIN-ed table if we found one conforming row.
      It stopped working in 5.0 as we return NESTED_LOOP_OK if we came upon
      that case in the evaluate_join_record() and that doesn't break the
      recordreading loop in sub_select().
      
      Fixed by returning NESTED_LOOP_NO_MORE_ROWS in this case.
      7abba3b0
  28. 27 Jan, 2008 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #33833. · 5e14047e
      igor@olga.mysql.com authored
      Two disjuncts containing equalities of the form key=const1 and key=const2 can
      be merged into one if const1 is equal to const2. To check it the common 
      collation of the constants were used rather than the collation of the field key.
      For example when the default collation of the constants was cases insensitive
      while the collation of the field was case sensitive, then two or-ed equality 
      predicates key='b' and key='B' incorrectly were merged into one f='b'. As a 
      result ref access was used instead of range access and wrong result sets were 
      returned in many cases. 
      Fixed the problem by comparing constant in the or-ed predicate with collation of
      the key field.
      5e14047e
  29. 18 Jan, 2008 1 commit
    • sergefp@mysql.com's avatar
      BUG#33794 "MySQL crashes executing specific query": · d56ac2f3
      sergefp@mysql.com authored
      The problem occurred when one had a subquery that had an equality X=Y where 
      Y referred to a named select list expression from the parent select. MySQL 
      crashed when trying to use the X=Y equality for ref-based access. 
      
      Fixed by allowing non-Item_field items in the described case.
      d56ac2f3
  30. 11 Jan, 2008 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #33697. · b85ffdb5
      igor@olga.mysql.com authored
      When the function test_if_skip_sort_order prefers index backward scan 
      to ref access the corresponding access functions must be set accordingly.
      b85ffdb5
  31. 20 Dec, 2007 2 commits
  32. 19 Dec, 2007 1 commit
  33. 12 Dec, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      Bug#12713 "Error in a stored function called from a SELECT doesn't · ebb9c5d9
      kostja@bodhi.(none) authored
      cause ROLLBACK of statement", part 1. Review fixes.
      
      Do not send OK/EOF packets to the client until we reached the end of 
      the current statement.
      This is a consolidation, to keep the functionality that is shared by all 
      SQL statements in one place in the server.
      Currently this functionality includes:
      - close_thread_tables()
      - log_slow_statement().
      
      After this patch and the subsequent patch for Bug#12713, it shall also include:
      - ha_autocommit_or_rollback()
      - net_end_statement()
      - query_cache_end_of_result().
      
      In future it may also include:
      - mysql_reset_thd_for_next_command().
      ebb9c5d9
  34. 11 Dec, 2007 1 commit
    • mhansson/martin@linux-st28.site's avatar
      Bug#32848: Data type conversion bug in union subselects in MySQL 5.0.38 · 867a7865
      mhansson/martin@linux-st28.site authored
      There were two problems when inferring the correct field types resulting from
      UNION queries.
      - If the type is NULL for all corresponding fields in the UNION, the resulting 
        type would be NULL, while the type is BINARY(0) if there is just a single 
        SELECT NULL.
      - If one SELECT in the UNION uses a subselect, a temporary table is created
        to represent the subselect, and the result type defaults to a STRING type,
        hiding the fact that the type was unknown(just a NULL value).
      Fixed by remembering whenever a field was created from a NULL value and pass
      type NULL to the type coercion if that is the case, and creating a string field
      as result of UNION only if the type would otherwise be NULL.
      867a7865
  35. 08 Dec, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #32815. · c394dbe1
      igor@olga.mysql.com authored
      The index (key_part_1, key_part-2) was erroneously considered as compatible
      with the required ordering in the function test_test_if_order_by_key when 
      a query with an ORDER BY clause contained a condition of the form
        key_part_1=const OR key_part_1 IS NULL 
      and the order list contained only key_part_2. This happened because the value
      of the const_key_parts field in the KEYUSE structure was not formed correctly
      for the keys that could be used for ref_or_null access. 
      This was fixed in the code of the update_ref_and_keys function.
      The problem could not manifest itself for MyISAM databases because the
      implementation of the keys_to_use_for_scanning() handler function always
      returns an empty bitmap for the MyISAM engine.
      c394dbe1
  36. 06 Dec, 2007 1 commit