1. 26 Aug, 2013 1 commit
  2. 28 Aug, 2013 3 commits
  3. 27 Aug, 2013 1 commit
    • Michael Widenius's avatar
      Fixed MySQL bug #69861 LAST_INSERT_ID is replicated incorrectly if replication filters are used · 112411b0
      Michael Widenius authored
      
      mysql-test/suite/rpl/r/last_insert_id.result:
        Test case for last_insert_id
      mysql-test/suite/rpl/t/last_insert_id.cnf:
        Test case for last_insert_id
      mysql-test/suite/rpl/t/last_insert_id.test:
        Test case for last_insert_id
      sql/log_event.cc:
        Added DBUG_PRINT
        Set thd->first_successful_insert_id_in_prev_stmt_for_binlog when setting thd->first_successful_insert_id_in_prev_stmt.
        This is required to get last_insert_id() replicated.
        This is analog to how read_first_successful_insert_id_in_prev_stmt() works.
      sql/rpl_utility.cc:
        Added DBUG_PRINT
      112411b0
  4. 26 Aug, 2013 3 commits
    • Igor Babaev's avatar
      Fixed bug mdev-4952 · 650d3266
      Igor Babaev authored
      When in function remove_eq_conds() a sub-formula of the processed condition
      is replaced for another formula we should ensure that in the resulting
      formula AND/OR levels must alternate.
      650d3266
    • Igor Babaev's avatar
      Fixed bug mdev-4944. · 901737c9
      Igor Babaev authored
      The patch to fix mdev-4418 turned out to be incorrect.
      At the substitution of single row tables in make_join_statistics()
      the used multiple equalities may change and references to the new multiple
      equalities must be updated. The function remove_eq_conds() takes care of it and
      it should be called right after the substitution of single row tables.
      Calling it after the call of make_join_statistics was a mistake.
      901737c9
    • Sergey Petrunya's avatar
      Merge fix for MDEV-4942, 5.3->5.5 · 7907b9b4
      Sergey Petrunya authored
      7907b9b4
  5. 24 Aug, 2013 1 commit
    • Igor Babaev's avatar
      Fixed bug mdev-4942. · dbc84ff9
      Igor Babaev authored
      Made sure that degenerate conjunctions/disjunctions are obtained from
      AND/OR conditions.
      dbc84ff9
  6. 23 Aug, 2013 2 commits
    • Igor Babaev's avatar
      Merge · b9ce8e60
      Igor Babaev authored
      b9ce8e60
    • Igor Babaev's avatar
      Fixed bug mdev-4420. · 540eeebb
      Igor Babaev authored
      The code of JOIN::optimize that performed substitutions for the best equal
      field in all ref items did not take into account that a multiple equality
      could contain the result of the single-value subquery if the subquery is
      inexpensive. This code was corrected.
      Also made necessary corresponding corrections in the code of make_join_select().
      540eeebb
  7. 22 Aug, 2013 4 commits
  8. 21 Aug, 2013 3 commits
  9. 20 Aug, 2013 4 commits
  10. 19 Aug, 2013 4 commits
  11. 17 Aug, 2013 2 commits
  12. 15 Aug, 2013 4 commits
    • Igor Babaev's avatar
      Merge · 752d5d02
      Igor Babaev authored
      752d5d02
    • Igor Babaev's avatar
      Fixed bug mdev-4355. · fa7f6772
      Igor Babaev authored
      This patch almost totally revised the patch for bug mdev-4177.
      The latter had too many defects. In particular, it did not
      propagate multiple equalities formed when merging a degenerate
      disjunct into underlying AND formula.
      fa7f6772
    • Igor Babaev's avatar
      Merge 5.2->5.3 · 960720b1
      Igor Babaev authored
      960720b1
    • Igor Babaev's avatar
      Merge 5.1->5.2 · 7ba78277
      Igor Babaev authored
      7ba78277
  13. 14 Aug, 2013 1 commit
  14. 13 Aug, 2013 1 commit
    • Igor Babaev's avatar
      Fixed bug mdev-4894. · 6dd9f049
      Igor Babaev authored
      This a an old legacy performance bug.
      When a very selective range scan existed for the second table in a join,
      and, at the same time, there was another range condition depending on the
      fields of the first table, the optimizer chose a plan with
      'Range checked for each record'. This plan was extremely inefficient in
      comparison with the regular selective range scan.
      As a matter of fact the range scan chosen for each record was the same as
      that selective range scan. 
      
      Changed the test case for bug 24776 to preserve the old output for explain.
       
      6dd9f049
  15. 12 Aug, 2013 2 commits
  16. 08 Aug, 2013 4 commits