• unknown's avatar
    2 minor edits, plus · fdfb10f2
    unknown authored
    fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning"
    and
    fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog".
    Now we don't always write the non-trans update immediately to the binlog;
    if there is something in the binlog cache we write it to the binlog cache
    (because the non-trans update could depend on a trans table which was modified
    earlier in the transaction); then in case of ROLLBACK, we write the binlog
    cache to the binlog, wrapped with BEGIN/ROLLBACK.
    This guarantees that the slave does the same updates.
    For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it
    to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated,
    we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction
    terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog
    (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO
    SAVEPOINT in the binlog.
    
    Apart from this rare case of updates of mixed table types in transaction, the
    usual way is still clear the binlog cache at ROLLBACK, or chop it at
    ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which
    is fine).
    Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM".
    
    
    client/mysqldump.c:
      Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each.
    mysql-test/r/rpl_loaddata.result:
      result update
    mysql-test/t/rpl_loaddata.test:
      minor edit: simplifying the test.
    sql/handler.cc:
      Fix for BUG#873. See comments in code, and the description of the changeset.
    sql/log.cc:
      * Previously, if a query updated a non-transactional table we wrote it immediately
      to the real binlog. This causes a bug when the update is done inside a transaction
      and uses the content of an updated transactional table (because this makes
      a wrong order of queries in the binlog). So if the binlog cache is not empty,
      we write the query to the binlog cache; otherwise we can write it to the binlog.
      * Previously, when we flushed the binlog cache to the binlog, we wrapped it
      with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle
      transactions which update both transactional and non-transactional tables.
    sql/log_event.cc:
      The slave thread can leave a transaction if COMMIT or if ROLLBACK.
    sql/sql_class.h:
      prototype
    sql/sql_insert.cc:
      Fix for BUG#1113:
      this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE.
    sql/sql_parse.cc:
      Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
    fdfb10f2
sql_class.h 24.7 KB