1. 18 Dec, 2017 4 commits
  2. 14 Dec, 2017 1 commit
  3. 13 Dec, 2017 10 commits
  4. 12 Dec, 2017 1 commit
  5. 09 Dec, 2017 3 commits
    • Jan Lindström's avatar
      de76cbdc
    • Jan Lindström's avatar
      MDEV-14401: Stored procedure that declares a handler that catches... · feb8296e
      Jan Lindström authored
      MDEV-14401: Stored procedure that declares a handler that catches ER_LOCK_DEADLOCK error causes thd->is_error() assertion
      
      This was missing bug fix from MySQL wsrep i.e. Galera.
      Problem was that if stored procedure declares a handler that
      catches deadlock error, then the error may have been
      cleared in method sp_rcontext::handle_sql_condition().
      Use wsrep_conflict_state correctly to determine is the
      error already sent to client.
      
      Add test case for both this bug and MDEV-12837: WSREP: BF
      lock wait long. Test requires both fixes to pass.
      feb8296e
    • Jan Lindström's avatar
      MDEV-12837: WSREP: BF lock wait long · e66bb572
      Jan Lindström authored
      This is 10.1 version where no merge error exists.
      
      wsrep_on_check
              New check function. Galera can't be enabled
              if innodb-lock-schedule-algorithm=VATS.
      
      innobase_kill_query
              In Galera async kill we could own lock mutex.
      
      innobase_init
              If Variance-Aware-Transaction-Sheduling Algorithm (VATS) is
              used on Galera we refuse to start InnoDB.
      
      Changed innodb-lock-schedule-algorithm as read-only parameter
      as it was designed to be.
      
      lock_rec_other_has_expl_req,
      lock_rec_other_has_conflicting,
      lock_rec_lock_slow
      lock_table_other_has_incompatible
      lock_rec_insert_check_and_lock
      
              Change pointer to conflicting lock to normal pointer as this
              pointer contents could be changed later.
      e66bb572
  6. 07 Dec, 2017 2 commits
  7. 05 Dec, 2017 1 commit
  8. 03 Dec, 2017 1 commit
    • Monty's avatar
      MDEV-10688 rpl.rpl_row_log_innodb failed in buildbot · d7b0b8dd
      Monty authored
      Problem was that Binlog_checkpoint can happen at random times.
      Fixed by not write binlog_checkpoint for the rpl_log test.
      
      Other things:
      - Removed not used variable "$keep_gtid_events"
      - Added option for show_binlog_events to skip binlog_checkpoint
      d7b0b8dd
  9. 29 Nov, 2017 1 commit
  10. 24 Nov, 2017 2 commits
  11. 22 Nov, 2017 1 commit
  12. 21 Nov, 2017 4 commits
  13. 19 Nov, 2017 1 commit
  14. 17 Nov, 2017 2 commits
  15. 16 Nov, 2017 5 commits
  16. 15 Nov, 2017 1 commit
    • Andrei Elkin's avatar
      MDEV-9510 Segmentation fault in binlog thread causes crash · c7e38076
      Andrei Elkin authored
      With combination of --log-bin and Galera the server may crash
      reporting two characteristic stacks:
      
        /usr/sbin/mysqld(_ZN13MYSQL_BIN_LOG13mark_xid_doneEmb+0xc7)[0x7f182a8e2cb7]
        /usr/sbin/mysqld(binlog_background_thread+0x2b5)[0x7f182a8e3275]
      
      or
      
        /usr/sbin/mysqld(_ZN13MYSQL_BIN_LOG21do_checkpoint_requestEm+0x9d)[0x7ff395b2dafd]
        /usr/sbin/mysqld(_ZN13MYSQL_BIN_LOG20checkpoint_and_purgeEm+0x11)[0x7ff395b2db91]
        /usr/sbin/mysqld(_ZN13MYSQL_BIN_LOG16rotate_and_purgeEb+0xc2)[0x7ff395b300b2]
      
      The reason of the failure appears to be non-matching decrements for
        `xid_count_per_binlog::xid_count`
      which can occur when a transaction is executed having its connection issued
      `SET @@sql_log_bin=0`. In such case the xid count is not incremented but
      its decrements still runs to turn `binlog_xid_count_list` into improper state
      which the following FLUSH BINARY LOGS exposes through the crash.
      
      *Note_1*: the regression test reuses an existing galera.sql_log_bin
      which does not run stably (even in its base form) by mtr with --log-bin.
      
      *Note_2*: 10.0-galera branch is free of this issue having missed MDEV-7205
      fixes.
      c7e38076