-
Venkatesh Venugopal authored
STATEMENTES END UP IN BINLOG Problem ======= If storage engine supports RBR, we allow unsafe SQL statements into the binlog and a warning is logged in the error log when binlog_format= STATEMENT. But, the behavior is completely different when storage engine doesn't support RBR i.e, when binlog_format= STATEMENT, the query execution is interrupted and errored out with ER_BINLOG_UNSAFE_AND_STMT_ENGINE even though it can be logged in statement format. This behavior is different from the documentation. See https://dev.mysql.com/doc/refman/5.6/en/binary-log-mixed.html Fix === This patch aims at adding a check on binlog_format before calling my_error() and sets the appropriate warning flags if the command is found to be unsafe. So, unsafe SQL statements are now logged with a warning in the error log if binlog_format= STATEMENT and if storage engine is only capable of logging in statement format. Reviewed by Pedro Figueiredo <pedro.figueiredo@oracle.com>> Reviewed by Bill Qu <bill.qu@oracle.com>
Venkatesh Venugopal authoredSTATEMENTES END UP IN BINLOG Problem ======= If storage engine supports RBR, we allow unsafe SQL statements into the binlog and a warning is logged in the error log when binlog_format= STATEMENT. But, the behavior is completely different when storage engine doesn't support RBR i.e, when binlog_format= STATEMENT, the query execution is interrupted and errored out with ER_BINLOG_UNSAFE_AND_STMT_ENGINE even though it can be logged in statement format. This behavior is different from the documentation. See https://dev.mysql.com/doc/refman/5.6/en/binary-log-mixed.html Fix === This patch aims at adding a check on binlog_format before calling my_error() and sets the appropriate warning flags if the command is found to be unsafe. So, unsafe SQL statements are now logged with a warning in the error log if binlog_format= STATEMENT and if storage engine is only capable of logging in statement format. Reviewed by Pedro Figueiredo <pedro.figueiredo@oracle.com>> Reviewed by Bill Qu <bill.qu@oracle.com>
Loading