mariadb/mysql-test/suite
Alfranio Correia a0946fa3d1 BUG#50038 Deadlock on flush logs with concurrent DML and RBR
In auto-commit mode, updating both trx and non-trx tables (i.e. issuing a mixed
statement) causes the following sequence of events:

1 - "Flush trx changes" (MYSQL_BIN_LOG::write) - T1:
  1.1 - mutex_lock (&LOCK_log)
  1.2 - mutex_lock (&LOCK_prep_xids)
  1.3 - increase prepared_xids
  1.4 - mutex_unlock (&LOCK_prep_xids)
  1.5 - mutex_unlock (&LOCK_log)

2 - "Flush non-trx changes" (MYSQL_BIN_LOG::write) - T1:
  2.1 - mutex_lock (&LOCK_log)
  2.2 - mutex_unlock (&LOCK_log)

3. "unlog" - T1
  3.1 - mutex_lock (&LOCK_prep_xids)
  3.2 - decrease prepared xids
  3.3 - pthread_cond_signal(&COND_prep_xids);
  3.4 - mutex_unlock (&LOCK_prep_xids)

The "FLUSH logs" command produces the following sequence of events:

1 - "FLUSH logs" command (MYSQL_BIN_LOG::new_file_impl) - user thread:
  1.1 - mutex_lock (&LOCK_log)
  1.2 - mutex_lock (&LOCK_prep_xids)
  1.3 - while (prepared_xids)  pthread_cond_wait(..., &LOCK_prep_xids);
  1.4 - mutex_unlock (&LOCK_prep_xids)
  1.5 - mutex_unlock (&LOCK_log)

A deadlock will arise if T1 flushes the trx changes and thus increases
prepared_xids but before it is able to continue the execution and flush the
non-trx changes, an user thread calls the "FLUSH logs" command and wait that
the prepared_xids is decreased and gets to zero. However, T1 cannot proceed
with the call to "Flush non-trx changes" because it will block in the mutex
"LOCK_log" and by consequence cannot complete the execution and call the
unlog to decrease the prepared_xids.

To fix the problem, we ensure that the non-trx changes are always flushed
before the trx changes.

Note that if you call "Flush non-trx changes" and a concurrent "FLUSH logs" is
issued, the "Flush non-trx changes" may block, but a deadlock will never happen
because the prepared_xids will eventually get to zero. Bottom line, there will
not be any transaction able to increase the prepared_xids because they will
block in the mutex "LOCK_log" (MYSQL_BIN_LOG::write) and those that increased
the prepared_xids will eventually commit and decrease the prepared_xids.
2010-01-05 16:55:23 +00:00
..
binlog BUG#50038 Deadlock on flush logs with concurrent DML and RBR 2010-01-05 16:55:23 +00:00
bugs Bug #38205 Row-based Replication (RBR) causes inconsistencies: HA_ERR_FOUND_DUPP_KEY 2009-04-09 16:05:41 +03:00
federated merging 5.1 main -> rpl+2. Some manual work required mostly due to bug46640 2009-11-06 18:35:04 +02:00
funcs_1 merging from 5.1 to rep+2 starting at gca(5.1, next-mr) == build@mysql.com-20091104182209-iui387z35159aoyw 2009-11-30 14:34:39 +02:00
funcs_2 merge 5.0-> 5.1 2009-04-24 13:00:17 -04:00
ibmdb2i Bug#45983 ibmdb2i_create_index_option=1 not working for primary key 2009-07-08 14:40:01 +05:30
im Move instance manager tests to it's own suite 2007-08-29 19:02:33 +02:00
innodb Clean-up after applying innodb-zip-ss6129 snapshot: 2009-11-03 18:41:04 +04:00
jp Bug #45159 : some tests in suite "jp" fail in embedded server (use LOAD DATA) 2009-09-11 15:52:08 +03:00
large_tests Bug#27029 alter table ... enable keys crashes mysqld on large table 2007-06-21 12:45:56 -04:00
manual manual merge for bug_29136, bug#29309. 2007-10-13 23:12:50 +03:00
ndb WL#2687 WL#5072 BUG#40278 BUG#47175 2009-11-03 19:02:56 +00:00
ndb_team Merge BUG#43263 from 5.0-bugteam to 5.1-bugteam 2009-05-31 13:44:41 +08:00
parts merging 5.1 main -> 5.1-rep+2 -> 5.1-rep+3; binlog_unsafe , rpl_mysql_upgrade fail and are under treatment 2009-11-10 20:45:15 +02:00
rpl BUG#50038 Deadlock on flush logs with concurrent DML and RBR 2010-01-05 16:55:23 +00:00
rpl_ndb mergin 5.1 -> rep+2 -> rep+3. create_table_from_dump issue will be merged on the next step 2009-11-30 20:20:26 +02:00
stress Merge trift2.:/MySQL/M51/mysql-5.1 2008-02-22 16:14:27 +01:00
sys_vars Backport Post fix of result files after push of BUG#34227 2009-10-02 17:12:10 +08:00