1. 26 Apr, 2012 1 commit
  2. 27 Apr, 2012 1 commit
    • unknown's avatar
      Fix bug lp:985667, MDEV-229 · c04786d3
      unknown authored
      Analysis:
      
      The reason for the wrong result is the interaction between constant
      optimization (in this case 1-row table) and subquery optimization.
      
      - First the outer query is optimized, and 'make_join_statistics' finds that
      table t2 has one row, reads that row, and marks the whole table as constant.
      This also means that all fields of t2 are constant.
      
      - Next, we optimize the subquery in the end of the outer 'make_join_statistics'.
      The field 'f2' is considered constant, with value '3'. The subquery predicate
      is rewritten as the constant TRUE.
      
      - The outer query execution detects early that the whole query result is empty
      and calls 'return_zero_rows'. Since the query is with implicit grouping, we
      have to produce one row with special values for the aggregates (depending on
      each aggregate function), and NULL values for all non-aggregate fields.  This
      function calls 'no_rows_in_result' to set each aggregate function to the
      default value when it aggregates over an empty result, and then calls
      'send_data', which in turn evaluates each Item in the SELECT list.
      
      - When evaluation reaches the subquery predicate, it executes the subquery
      with field 'f2' having a constant value '3', and the subquery produces the
      incorrect result '7'.
      
      Solution:
      
      Implement Item::no_rows_in_result for all subquery predicates. In order to
      make this work, it is also needed to make all val_* methods of all subquery
      predicates respect the Item_subselect::forced_const flag. Otherwise subqueries
      are executed anyways, and override the default value set by no_rows_in_result
      with whatever result is produced from the subquery evaluation.
      c04786d3
  3. 23 Apr, 2012 2 commits
  4. 20 Apr, 2012 1 commit
    • Vladislav Vaintroub's avatar
      LPBUG#983285 - incompatibility in frm in case of VIEWs with non-default ALGORITHM option. · 97aa8e8c
      Vladislav Vaintroub authored
      As part of derived tables redesign, values for VIEW_ALGORITHM_MERGE and VIEW_ALGORITHM_TMPTABLE have changed from (former values 1 rsp 2 , new values 5 rsp 9).
      
      This lead to the problem that views, created with version 5.2  or earlier would not work in all situations  (e.g "SHOW CREATE VIEW"), or with mysqldump.
      
      The fix is to restore backward compatibility for the from file, and convert algorithm={1,2} in the frm to {5,9} when reading .frm from disk, and store backward compatible values when writing from to disk. 
      
      Also allow processing correct processing for "invalid" .frms created with MariaDB 5.3/5.5 GA releases (where algorithm stored in memory matched the one stored in frm).
      97aa8e8c
  5. 19 Apr, 2012 3 commits
    • unknown's avatar
      LP BUG#978847 fixed. · 9997b78a
      unknown authored
      Fixed incorrect type casting which made all fields (except very first) changes to materialized table incorrect.
      Saved list of view/derived table used items after expanding '*'.
      9997b78a
    • Sergey Petrunya's avatar
      BUG#978479: Wrong result (extra rows) with... · b9bbe4a1
      Sergey Petrunya authored
      BUG#978479: Wrong result (extra rows) with derived_with_keys+loosescan+semijoin=ON, materialization=OFF
      - Part#2: Don't try to construct a LooseScan access on indexes that do not guarantee 
        index-ordered reads.
      
      b9bbe4a1
    • Sergey Petrunya's avatar
      BUG#978479: Wrong result (extra rows) with... · 994c6db2
      Sergey Petrunya authored
      BUG#978479: Wrong result (extra rows) with derived_with_keys+loosescan+semijoin=ON, materialization=OFF
      Part#1: make EXPLAIN's plan match the one by actual execution: 
      Item_subselect::used_tables() should return the same value irrespectively 
      of whether we're running an EXPLAIN or a SELECT.
      994c6db2
  6. 16 Apr, 2012 7 commits
  7. 08 Apr, 2012 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #972943 properly. · f081107f
      Igor Babaev authored
      The previous patch for the bug (that erroneously identified the bug as
      bug 972973 in its comment) was incorrect. 
      It turned out that the code that triggered the abort complain reported for
      the bug was not needed at all.
      f081107f
  8. 07 Apr, 2012 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #972973. · b95ae56b
      Igor Babaev authored
      When the function free_tmp_table deletes the handler object for
      a temporary table the field TABLE::file for this table should be
      set to NULL. Otherwise an assertion failure may occur.
      b95ae56b
  9. 06 Apr, 2012 6 commits
  10. 05 Apr, 2012 4 commits
    • Sergei Golubchik's avatar
      merge · a3073ecd
      Sergei Golubchik authored
      a3073ecd
    • unknown's avatar
      Fix of LP bug#968720. · 1a489190
      unknown authored
      When a view/derived table is converted from merged to materialized the
      items from the used_item lists are substituted for items referring to
      the fields of the result of the materialization. The problem appeared
      with queries employing natural joins. Since the resolution of a natural
      join was performed only once the used_item list formed at the second
      execution of the query lacked the references to the fields that were
      used only in the equality predicates generated for the natural join.
      1a489190
    • Sergei Golubchik's avatar
      merge · cbd52a42
      Sergei Golubchik authored
      cbd52a42
    • Sergei Golubchik's avatar
      mysql-5.1.62 merge · dea3544b
      Sergei Golubchik authored
      dea3544b
  11. 04 Apr, 2012 8 commits
  12. 03 Apr, 2012 4 commits
  13. 02 Apr, 2012 1 commit