1. 26 Jan, 2016 1 commit
  2. 25 Jan, 2016 19 commits
  3. 24 Jan, 2016 1 commit
    • Sergei Petrunia's avatar
      MDEV-9457: Poor query plan chosen for ORDER BY query by a recent 10.1 · ff8d4009
      Sergei Petrunia authored
      Undo the change in test_if_skip_sort_order() that set ref_key=-1 when
      a variant of index_merge is used (was made in fix for MDEV-9021).
      
      It turned out that test_if_cheaper_ordering() call below assumes that
      ref_key=-1 means "no index is used", that is, "an inefficient full table
      scan is done".
      This is not the same as index_merge, index_merge can actually be quite
      efficient. So, ref_key=MAX_KEY denotes the fact that some index is used,
      not any given index.
      ff8d4009
  4. 22 Jan, 2016 1 commit
  5. 20 Jan, 2016 3 commits
  6. 19 Jan, 2016 3 commits
  7. 17 Jan, 2016 7 commits
  8. 15 Jan, 2016 5 commits
    • Kristian Nielsen's avatar
      After-merge fix. · 38bcb446
      Kristian Nielsen authored
      38bcb446
    • Kristian Nielsen's avatar
      Merge branch 'tmp' into tmp-10.1 · 2f88b14a
      Kristian Nielsen authored
      Conflicts:
      	sql/slave.cc
      2f88b14a
    • Kristian Nielsen's avatar
      Merge branch 'tmp' into tmp-10.0 · 74b1af19
      Kristian Nielsen authored
      Conflicts:
      	sql/slave.cc
      74b1af19
    • Kristian Nielsen's avatar
      Fix error handling for GTID and domain-based parallel replication · 06b2e327
      Kristian Nielsen authored
      This occurs when replication stops with an error, domain-based parallel
      replication is used, and the GTID position contains more than one domain.
      Furthermore, it relates to the case where the SQL thread is restarted
      without first stopping the IO thread.
      
      In this case, the file/offset relay-log position does not correctly
      represent the slave's multi-dimensional position, because other domains may
      be far ahead of, or behind, the domain with the failing event. So the code
      reverts the relay log position back to the start of a relay log file that is
      known to be before all active domains.
      
      There was a bug that when the SQL thread was restarted, the
      rli->relay_log_state was incorrectly initialised from @@gtid_slave_pos. This
      position will likely be too far ahead, due to reverting the relay log
      position. Thus, if the replication fails again after the SQL thread restart,
      the rli->restart_gtid_pos might be updated incorrectly. This in turn would
      cause a second SQL thread restart to replicate from the wrong position, if
      the IO thread was still left running.
      
      The fix is to initialise rli->relay_log_state from @@gtid_slave_pos only
      when we actually purge and re-fetch relay logs from the master, not at every
      SQL thread start.
      
      A related problem is the use of sql_slave_skip_counter to resolve
      replication failures in this kind of scenario. Since the slave position is
      multi-dimensional, sql_slave_skip_counter can not work properly - it is
      indeterminate exactly which event is to be skipped, and is unlikely to work
      as expected for the user. So make this an error in the case where
      domain-based parallel replication is used with multiple domains, suggesting
      instead the user to set @@gtid_slave_pos to reliably skip the desired event.
      06b2e327
    • Alexey Botchkov's avatar
      MDEV-9106 Audit plugin not working with MySQL 5.7. · 9c9d10b4
      Alexey Botchkov authored
              fixing Windows crash.
      9c9d10b4