MySQL Bug#56184 Rolled back transaction without non-trasactional table updated was binlogged

revno: 2876.438.1

committer: <anders.song@greatopensource.com>

branch nick: mysql-trunk

timestamp: Wed 2011-01-05 13:21:07 +0800

message:

  Bug#56184 Rolled back transaction without non-trasactional table updated was binlogged

  Bug#55798 Slave SQL retry on transaction inserts extra data into non-transaction table

  The transaction modified non-transactional table will be binlogged with ROLLBACK if it

  rolls back on master. It includes the case that all statements which modified

  non-transactional table are binlogged outside(before) the transaction.

  Example:

    BEGIN

    INSERT INTO trans-table;

    INSERT INOT non-trans-table;

    ROLLBACK

  it will be binlogged as:

    BEGIN

    INSERT INTO non-trans-table;

    COMMIT

    BEGIN

    INSERT INTO trans-table;

    ROLLBACK;

  All statements in the second binlogged transaction modify only transactional tables and

  are rolled back safely on master. So the second transaction should not be binlogged.

  After 5.5, there are two caches for binary logs, a transactional cache

  and a statement cache. When executing a transaction, statements that

  modified only transactional tables are always put in transactional

  cache. Statements that modified non-transactional tables can be put in

  either transactional or non-transactional cache depending on different

  situations. In this patch, a flag is added to mark if there is any

  statement that modified non-transactional table in transactional cache.

  When rolling back a transaction on master, transactional cache should

  not be flushed to binary log, if there is no statement in it that

  modified a non-transactional table. Otherwise, it should be flushed into

  binary log followed by 'ROLLBACK' statement.

  BUG#55798

  When a temporary error(eg. Lock timeout) happens, Slave SQL thread will rollback the

  transaction and retry it again. But it is possible that the transaction cannot be

  rolled back safely. For example a non-transactional table has been modified by the

  transaction. It will make master and slave diversely.

  After this patch, SQL thread will not retry to execute a transaction which can not be rolled

  back safely if temporary error is encountered.

  It also did some refactoring on code related to THD_TRANS::modified_non_trans_table and

  binlog_cache_data.