1. 16 Mar, 2017 1 commit
    • Monty's avatar
      Removed wrong assert · e7f55fde
      Monty authored
      The following is an updated commit message for the following commit
      that was pushed before I had a chance to update the commit message:
      c5e25c8b
      
      Fixed dead locks when doing stop slave while slave was starting.
      
      - Added a separate lock for protecting start/stop/reset of a specific slave.
        This solves some possible dead locks when one calls stop slave while
        the slave is starting as the old run_locks was over used for other things.
      - Set hash->records to 0 before calling free of all hash elements.
        This was set to stop concurrent threads to loop over hash elements and
        access members that was already freed.
        This was a problem especially in start_all_slaves/stop_all_slaves
        as the mutex protecting the hash was temporarily released while a slave
        was started/stopped.
      - Because of change to hash->records during hash_reset(),
        any_slave_sql_running() will return 1 during shutdown as one can't
        loop over master_info_index->master_info_hash while hash_reset() of it
        is in progress.
        This also fixes a potential old bug in any_slave_sql_running() where
        during shutdown and ~Master_info_index(), my_hash_free() we could
        potentially try to access elements that was already freed.
      e7f55fde
  2. 15 Mar, 2017 1 commit
  3. 13 Mar, 2017 1 commit
  4. 10 Mar, 2017 1 commit
    • Marko Mäkelä's avatar
      MDEV-12091 Shutdown fails to wait for rollback of recovered transactions to finish · 032678ad
      Marko Mäkelä authored
      In the 10.1 InnoDB Plugin, a call os_event_free(buf_flush_event) was
      misplaced. The event could be signalled by rollback of resurrected
      transactions while shutdown was in progress. This bug was caught
      by cmake -DWITH_ASAN testing. This call was only present in the
      10.1 InnoDB Plugin, not in other versions, or in XtraDB.
      
      That said, the bug affects all InnoDB versions. Shutdown assumes the
      cessation of any page-dirtying activity, including the activity of
      the background rollback thread. InnoDB only waited for the background
      rollback to finish as part of a slow shutdown (innodb_fast_shutdown=0).
      The default is a clean shutdown (innodb_fast_shutdown=1). In a scenario
      where InnoDB is killed, restarted, and shut down soon enough, the data
      files could become corrupted.
      
      logs_empty_and_mark_files_at_shutdown(): Wait for the
      rollback to finish, except if innodb_fast_shutdown=2
      (crash-like shutdown) was requested.
      
      trx_rollback_or_clean_recovered(): Before choosing the next
      recovered transaction to roll back, terminate early if non-slow
      shutdown was initiated. Roll back everything on slow shutdown
      (innodb_fast_shutdown=0).
      
      srv_innodb_monitor_mutex: Declare as static, because the mutex
      is only used within one module.
      
      After each call to os_event_free(), ensure that the freed event
      is not reachable via global variables, by setting the relevant
      variables to NULL.
      032678ad
  5. 09 Mar, 2017 4 commits
  6. 08 Mar, 2017 10 commits
  7. 06 Mar, 2017 4 commits
  8. 05 Mar, 2017 10 commits
  9. 04 Mar, 2017 5 commits
  10. 03 Mar, 2017 3 commits