1. 28 Aug, 2013 4 commits
  2. 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
  3. 26 Aug, 2013 5 commits
  4. 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
  5. 23 Aug, 2013 3 commits
  6. 22 Aug, 2013 4 commits
  7. 21 Aug, 2013 3 commits
  8. 20 Aug, 2013 4 commits
  9. 19 Aug, 2013 4 commits
  10. 17 Aug, 2013 2 commits
  11. 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
  12. 14 Aug, 2013 1 commit
  13. 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
  14. 12 Aug, 2013 2 commits
  15. 08 Aug, 2013 1 commit