1. 01 May, 2015 1 commit
  2. 30 Apr, 2015 1 commit
  3. 29 Apr, 2015 3 commits
    • Alexander Barkov's avatar
      A clean-up for c8141f53 · 499deca7
      Alexander Barkov authored
      MDEV-7950 Item_func::type() takes 0.26% in OLTP RO (Step#2)
      
      - Item_ref was doing unnecessary extra job after the "MDEV-7950 Step#2" patch.
        Fallback to Item::build_equal_items() if real_type() is not FIELD_ITEM.
        Note, Item_ref::build_equal_items() will most likely be further simplified.
        Waiting for Sanja and Igor to check a possibly dead code.
      
      - Safety: Adding Item_sum::build_equal_items() with ASSERT, as Item_sum
        should never appear in build_equal_items() context.
      499deca7
    • Kristian Nielsen's avatar
      Merge branch '10.0' into 10.1 · 9cdf5c2b
      Kristian Nielsen authored
      9cdf5c2b
    • Kristian Nielsen's avatar
      MDEV-7802: group commit status variable addition · 9088f26f
      Kristian Nielsen authored
      Backport into 10.0
      9088f26f
  4. 28 Apr, 2015 2 commits
    • Alexander Barkov's avatar
      MDEV-7950 Item_func::type() takes 0.26% in OLTP RO · c8141f53
      Alexander Barkov authored
      Step#2:
      
      1. Removes the function build_equal_items_for_cond() and
         introduces a new method Item::build_equal_items() instead,
         with specific implementations in the following Items:
      
         Item  (the default implementation)
         Item_ident_or_func_or_sum
         Item_cond
         Item_cond_and
      
      2. Adds a new abstract class Item_ident_or_func_or_sum,
         a common parent for Item_ident and Item_func_or_sum,
         as they have exactly the same build_equal_items().
      
      3. Renames Item_cond_and::cond_equal to Item_cond_and::m_cond_equal,
         to avoid confusion between the member and local variables named
         "cond_equal".
      c8141f53
    • Kristian Nielsen's avatar
      MDEV-7864: Slave SQL: stopping on non-last RBR event with annotations results in SEGV (signal 11) · ed701c6a
      Kristian Nielsen authored
      The slave SQL thread was clearing serial_rgi->thd before deleting
      serial_rgi, which could cause access to NULL THD.
      
      The clearing was introduced in commit
      2e100cc5 and is just plain wrong. So revert
      that part (single line) of that commit.
      
      Thanks to Daniel Black for bug analysis and test case.
      ed701c6a
  5. 25 Apr, 2015 1 commit
  6. 24 Apr, 2015 3 commits
  7. 23 Apr, 2015 2 commits
    • Kristian Nielsen's avatar
      Merge MDEV-8031 into 10.1 · c2dd88ac
      Kristian Nielsen authored
      c2dd88ac
    • Kristian Nielsen's avatar
      MDEV-8031: Parallel replication stops on "connection killed" error (probably... · b616991a
      Kristian Nielsen authored
      MDEV-8031: Parallel replication stops on "connection killed" error (probably incorrectly handled deadlock kill)
      
      There was a rare race, where a deadlock error might not be correctly
      handled, causing the slave to stop with something like this in the error
      log:
      
      150423 14:04:10 [ERROR] Slave SQL: Connection was killed, Gtid 0-1-2, Internal MariaDB error code: 1927
      150423 14:04:10 [Warning] Slave: Connection was killed Error_code: 1927
      150423 14:04:10 [Warning] Slave: Deadlock found when trying to get lock; try restarting transaction Error_code: 1213
      150423 14:04:10 [Warning] Slave: Connection was killed Error_code: 1927
      150423 14:04:10 [Warning] Slave: Connection was killed Error_code: 1927
      150423 14:04:10 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'master-bin.000001 position 1234
      
      The problem was incorrect error handling. When a deadlock is detected, it
      causes a KILL CONNECTION on the offending thread. This error is then later
      converted to a deadlock error, and the transaction is retried.
      
      However, the deadlock error was not cleared at the start of the retry, nor
      was the lingering kill signal. So it was possible to get another deadlock
      kill early during retry. If this happened with particular thread
      scheduling/timing, it was possible that the new KILL CONNECTION error was
      masked by the earlier deadlock error, so that the second kill was not
      properly converted into a deadlock error and retry.
      
      This patch adds code that clears the old error and killed flag before
      starting the retry. It also adds code to handle a deadlock kill caught in a
      couple of places where it was not handled before.
      b616991a
  8. 22 Apr, 2015 1 commit
  9. 21 Apr, 2015 2 commits
  10. 20 Apr, 2015 6 commits
  11. 19 Apr, 2015 1 commit
  12. 17 Apr, 2015 7 commits
  13. 16 Apr, 2015 1 commit
  14. 15 Apr, 2015 2 commits
  15. 14 Apr, 2015 4 commits
  16. 13 Apr, 2015 3 commits