1. 12 Jul, 2011 1 commit
  2. 11 Jul, 2011 4 commits
    • Sergey Petrunya's avatar
      Port of code for: (part of testcase is in mysql-test/t/subquery*.test and will... · 2c28412e
      Sergey Petrunya authored
      Port of code for: (part of testcase is in mysql-test/t/subquery*.test and will be ported separately)
      
      Bug#11766642: crash in Item_field::register_field_in_read_map 
                    with view
      
      (Former 59793)
      
      Prior to the refactoring in this patch, Item_cond_xor behaved 
      partially as an Item_cond and partially as an Item_func. The
      reasoning behind this was that XOR is currently not optimized
      (thus should be Item_func instead of Item_cond), but it was 
      planned optimize it in the future (thus, made Item_cond anyway 
      to ease optimization later). 
      
      Even though Item_cond inherits from Item_func, there are 
      differences between these two. One difference is that the 
      arguments are stored differently. Item_cond stores them in a 
      list while Item_func store them in an args[]. 
      
      BUG no 45221 was caused by Item_cond_xor storing arguments in 
      the list while users of the objects would look for them in 
      args[]. The fix back then was to store the arguments in both 
      locations.
      
      In this bug, Item_cond_xor initially gets two Item_field 
      arguments. These are stored in the list inherited from 
      Item_cond and in args[] inherited from Item_func. During
      resolution, find_field_in_view() replaces the Item_fields 
      stored in the list with Item_direct_view_refs, but args[] 
      still points to the unresolved Item_fields. This shows that 
      the fix for 45221 was incorrect.
      
      The refactoring performed in this patch removes the confusion
      by making the XOR item an Item_func period. A neg_transformer() 
      is also implemented for Item_func_xor to improve performance 
      when negating XOR expressions. An XOR is negated by negating 
      one of the operands.
      2c28412e
    • Igor Babaev's avatar
      Fixed LP bug #793386. · 47aee198
      Igor Babaev authored
      Auto-generated names for view field items must be allocated in
      the statement memory, not in the execution memory of the statement.
      47aee198
    • Sergey Petrunya's avatar
      Alternate version of MySQL's fix for BUG#49453. · 62cc4df4
      Sergey Petrunya authored
      The cause of the crash is sj_nest->sj_subq_pred->unit->first_select()->item_list
      contains "stale" items for the second execution. By "stale" I mean that they have
      item->fixed==FALSE, and they are Item_field object instead of Item_direct_view_ref.
      
      The solution is to use sj_nest->sj_subq_pred->unit->first_select()->ref_pointer_array.
      Surprisingly, that array contains items that are ok.
      
      Oracle team has introduced and is using NESTED_JOIN::sj_inner_exprs, but we go without that
      and always copy the ref_pointer_array.
      
      62cc4df4
    • Igor Babaev's avatar
      Fixed LP bug #806504. · f8db35bd
      Igor Babaev authored
      Missing initialization of the bitmap not_null_tables_cache to 0 
      in the function Item_func::eval_not_null_tables caused this bug.
      This function is called indirectly from the function
      SELECT_LEX::update_used_tables after merging mergeable views and
      derived tables into the main query. The leaf tables of resulting
      query may change their bitmap numbers after this merge. That's why
      the not_null_tables_cache bitmaps must be updated. Due to the bug 
      mentioned above the result of the re-evaluation of the 
      not_null_tables_cache turned out to be incorrect in some cases.
      This could trigger an invalid conversion of outer joins into 
      inner joins leading to invalid query result sets.
      
      Also removed an implicit conversion from int to bool in the function
      SELECT_LEX::update_used_tables.
      f8db35bd
  3. 10 Jul, 2011 6 commits
  4. 09 Jul, 2011 3 commits
  5. 08 Jul, 2011 9 commits
  6. 07 Jul, 2011 7 commits
    • Igor Babaev's avatar
      Merge. · f222a513
      Igor Babaev authored
      f222a513
    • Igor Babaev's avatar
      Fixed LP bug #806477. · e55e78ee
      Igor Babaev authored
      The offending query returns a wrong result set because the optimizer
      erroneously eliminated the where condition evaluated it to TRUE.
      The cause of this wrong transformation was that the flag maybe_null
      for an inner table of the outer join was not set to TRUE after the 
      table had replaced the wrapping view.
      Now the function SELECT_LEX::update_used_tables resets the value
      of the maybe_null flag for each leaf table of the query after all
      merges of views have been done.
      
       
      e55e78ee
    • unknown's avatar
      Test for bug lp:612543 · 0f36ab3a
      unknown authored
      The bug itself has been fixed by MWL#89.
      0f36ab3a
    • unknown's avatar
      Test case for bug lp:611690 · 5f5cbf76
      unknown authored
      The bug itself has been fixed by MWL#89.
      5f5cbf76
    • unknown's avatar
      Fix bug lp:806943 · 4128ec48
      unknown authored
      Analysis:
      This bug is yet another incarnation of the generic problem
      where optimization of the outer query triggers evaluation
      of a subquery, and this evaluation performs a destructive
      change to the subquery plan. Specifically a temp table is
      created for the DISTINCT operation that replaces the
      original subquery table. Later, select_describe() attempts
      to print the table name, however, there is no corresponding
      TABLE_LIST object to the internal temp table, so we get a
      crash. Execution works fine because it is not interested in
      the corresponding TABLE_LIST object (or its name).
      
      Solution:
      Similar to other such bugs, block the evaluation of expensive
      Items in convert_const_to_int().
      4128ec48
    • Igor Babaev's avatar
      Merge. · 801a4ebc
      Igor Babaev authored
      801a4ebc
    • Igor Babaev's avatar
      Fixed LP bug #806431. · b79316f5
      Igor Babaev authored
      The function generate_derived_keys_for_table incorrectly handled
      the cases when a materialized view or derived table could be accessed
      by different keys on the same fields if these keys depended on the
      same tables.
        
      b79316f5
  7. 06 Jul, 2011 4 commits
  8. 05 Jul, 2011 6 commits