• Luis Soares's avatar
    BUG#51251: Wrong binlogging in case of TRUNCATE <temporary InnoDB table> · 48d65a64
    Luis Soares authored
    For temporary tables that are created with an engine that does
    not provide the HTON_CAN_RECREATE, the truncate operation is
    performed resorting to the optimized handler::ha_delete_all_rows
    method. However, this means that the truncate will share
    execution path, from mysql_delete, with truncate on regular
    tables and other delete operations. As a consequence the truncate
    operation, for the temporary table is logged, even if in row mode
    because there is no distinction between this and the other delete
    operations at binlogging time.
    
    We fix this by checking if: (i) the binlog format, when the
    truncate operation was issued, is ROW; (ii) if the operation is a
    truncate; and (iii) if the table is a temporary table; before
    writing to the binary log. If all three conditions are met, we
    skip writing to the binlog. A side effect of this fix is that we
    limit the scope of setting and resetting the
    current_stmt_binlog_row_based. Now we just set and reset it
    inside mysql_delete in the boundaries of the
    handler::ha_write_row loop. This way we have access to
    thd->current_stmt_binlog_row_based real value inside
    mysql_delete.
    
    mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
      Updated result for spurious truncate table.
    mysql-test/suite/binlog/t/binlog_row_innodb_truncate.test:
      Test case.
    sql/sql_delete.cc:
      Added check in mysql_delete before writing the TRUNCATE statement
      to the binary log. Additionally, removed the set/reset of
      current_stmt_binlog_row_based so that it happens just in the 
      boundaries of the handler::ha_write_row loop inside mysql_delete.
    48d65a64
sql_delete.cc 35.3 KB