General overview:
The logic for switching to row format when binlog_format=MIXED had
numerous flaws. The underlying problem was the lack of a consistent
architecture.
General purpose of this changeset:
This changeset introduces an architecture for switching to row format
when binlog_format=MIXED. It enforces the architecture where it has
to. It leaves some bugs to be fixed later. It adds extensive tests to
verify that unsafe statements work as expected and that appropriate
errors are produced by problems with the selection of binlog format.
It was not practical to split this into smaller pieces of work.
Problem 1:
To determine the logging mode, the code has to take several parameters
into account (namely: (1) the value of binlog_format; (2) the
capabilities of the engines; (3) the type of the current statement:
normal, unsafe, or row injection). These parameters may conflict in
several ways, namely:
- binlog_format=STATEMENT for a row injection
- binlog_format=STATEMENT for an unsafe statement
- binlog_format=STATEMENT for an engine only supporting row logging
- binlog_format=ROW for an engine only supporting statement logging
- statement is unsafe and engine does not support row logging
- row injection in a table that does not support statement logging
- statement modifies one table that does not support row logging and
one that does not support statement logging
Several of these conflicts were not detected, or were detected with
an inappropriate error message. The problem of BUG#39934 was that no
appropriate error message was written for the case when an engine
only supporting row logging executed a row injection with
binlog_format=ROW. However, all above cases must be handled.
Fix 1:
Introduce new error codes (sql/share/errmsg.txt). Ensure that all
conditions are detected and handled in decide_logging_format()
Problem 2:
The binlog format shall be determined once per statement, in
decide_logging_format(). It shall not be changed before or after that.
Before decide_logging_format() is called, all information necessary to
determine the logging format must be available. This principle ensures
that all unsafe statements are handled in a consistent way.
However, this principle is not followed:
thd->set_current_stmt_binlog_row_based_if_mixed() is called in several
places, including from code executing UPDATE..LIMIT,
INSERT..SELECT..LIMIT, DELETE..LIMIT, INSERT DELAYED, and
SET @@binlog_format. After Problem 1 was fixed, that caused
inconsistencies where these unsafe statements would not print the
appropriate warnings or errors for some of the conflicts.
Fix 2:
Remove calls to THD::set_current_stmt_binlog_row_based_if_mixed() from
code executed after decide_logging_format(). Compensate by calling the
set_current_stmt_unsafe() at parse time. This way, all unsafe statements
are detected by decide_logging_format().
Problem 3:
INSERT DELAYED is not unsafe: it is logged in statement format even if
binlog_format=MIXED, and no warning is printed even if
binlog_format=STATEMENT. This is BUG#45825.
Fix 3:
Made INSERT DELAYED set itself to unsafe at parse time. This allows
decide_logging_format() to detect that a warning should be printed or
the binlog_format changed.
Problem 4:
LIMIT clause were not marked as unsafe when executed inside stored
functions/triggers/views/prepared statements. This is
BUG#45785.
Fix 4:
Make statements containing the LIMIT clause marked as unsafe at
parse time, instead of at execution time. This allows propagating
unsafe-ness to the view.
without proper formatting
The problem is that a suitably crafted database identifier
supplied to COM_CREATE_DB or COM_DROP_DB can cause a SIGSEGV,
and thereby a denial of service. The database name is printed
to the log without using a format string, so potential
attackers can control the behavior of my_b_vprintf() by
supplying their own format string. A CREATE or DROP privilege
would be required.
This patch supplies a format string to the printing of the
database name. A test case is added to mysql_client_test.
sql/sql_parse.cc:
Added format strings.
tests/mysql_client_test.c:
Added new test case.
without proper formatting
The problem is that a suitably crafted database identifier
supplied to COM_CREATE_DB or COM_DROP_DB can cause a SIGSEGV,
and thereby a denial of service. The database name is printed
to the log without using a format string, so potential
attackers can control the behavior of my_b_vprintf() by
supplying their own format string. A CREATE or DROP privilege
would be required.
This patch supplies a format string to the printing of the
database name. A test case is added to mysql_client_test.
queries if query was killed
Since we rely on thd->is_error() to decide whether we should
COMMIT or ROLLBACK after a query execution, check the query
'killed' state and throw an error before calling
ha_autocommit_or_rollback(), not after.
The patch was tested manually. For reliable results, the test
case would have to KILL QUERY while a DELETE/UPDATE query in
another thread is still running. I don't see a way to achieve
this kind of synchronization in our test suite (no debug_sync
in 5.1).
sql/sql_parse.cc:
Since we rely on thd->is_error() to decide whether we should
COMMIT or ROLLBACK after query execution, check the query
'killed' state and throw an error before calling
ha_autocommit_or_rollback(), not after.
queries if query was killed
Since we rely on thd->is_error() to decide whether we should
COMMIT or ROLLBACK after a query execution, check the query
'killed' state and throw an error before calling
ha_autocommit_or_rollback(), not after.
The patch was tested manually. For reliable results, the test
case would have to KILL QUERY while a DELETE/UPDATE query in
another thread is still running. I don't see a way to achieve
this kind of synchronization in our test suite (no debug_sync
in 5.1).
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the second patch, fixing more
of the warnings.
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the second patch, fixing more
of the warnings.
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the second patch, fixing more
of the warnings.
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the second patch, fixing more
of the warnings.
the problem is in the TIMESTAMP(14) fields of the access-control tables.
The TIMESTAMP(14) syntax is marked as DEPRECATED since 5.2.
Fixed by just changed the check to 6.0 as it's done in the 5.1 branch.
per-file comments:
sql/sql_parse.cc
Bug#44394 Assertion Failure
now it's deprecated since 6.0
the problem is in the TIMESTAMP(14) fields of the access-control tables.
The TIMESTAMP(14) syntax is marked as DEPRECATED since 5.2.
Fixed by just changed the check to 6.0 as it's done in the 5.1 branch.
per-file comments:
sql/sql_parse.cc
Bug#44394 Assertion Failure
now it's deprecated since 6.0
MySQL crashes if a user without proper privileges attempts to create a procedure.
The crash happens because more than one error state is pushed onto the Diagnostic
area. In this particular case the user is denied to implicitly create a new user
account with the implicitly granted privileges ALTER- and EXECUTE ROUTINE.
The new account is needed if the original user account contained a host mask.
A user account with a host mask is a distinct user account in this context.
An alternative would be to first get the most permissive user account which
include the current user connection and then assign privileges to that
account. This behavior change is considered out of scope for this bug patch.
The implicit assignment of privileges when a user creates a stored routine is a
considered to be a feature for user convenience and as such it is not
a critical operation. Any failure to complete this operation is thus considered
non-fatal (an error becomes a warning).
The patch back ports a stack implementation of the internal error handler interface.
This enables the use of multiple error handlers so that it is possible to intercept
and cancel errors thrown by lower layers. This is needed as a error handler already
is used in the call stack emitting the errors which needs to be converted.
mysql-test/r/grant.result:
* Added test case for bug44658
mysql-test/t/grant.test:
* Added test case for bug44658
sql/sp.cc:
* Removed non functional parameter no_error and my_error calls as all errors
from this function will be converted to a warning anyway.
* Change function return type from int to bool.
sql/sp.h:
* Removed non functional parameter no_error and my_error calls as all errors
from this function will be converted to a warning anyway.
* Changed function return value from int to bool
sql/sql_acl.cc:
* Removed the non functional no_error parameter from the function prototype.
The function is called from two places and in one of the places we now
ignore errors through error handlers.
* Introduced the parameter write_to_binlog
* Introduced an error handler to cancel any error state from mysql_routine_grant.
* Moved my_ok() signal from mysql_routine_grant to make it easier to avoid
setting the wrong state in the Diagnostic area.
* Changed the broken error state in sp_grant_privileges() to a warning
so that if "CREATE PROCEDURE" fails because "Password hash isn't a hexidecimal
number" it is still clear what happened.
sql/sql_acl.h:
* Removed the non functional no_error parameter from the function prototype.
The function is called from two places and in one of the places we now
ignore errors through error handlers.
* Introduced the parameter write_to_binlog
* Changed return type for sp_grant_privileges() from int to bool
sql/sql_class.cc:
* Back ported implementation of internal error handler from 6.0 branch
sql/sql_class.h:
* Back ported implementation of internal error handler from 6.0 branch
sql/sql_parse.cc:
* Moved my_ok() signal from mysql_routine_grant() to make it easier to avoid
setting the wrong state in the Diagnostic area.
MySQL crashes if a user without proper privileges attempts to create a procedure.
The crash happens because more than one error state is pushed onto the Diagnostic
area. In this particular case the user is denied to implicitly create a new user
account with the implicitly granted privileges ALTER- and EXECUTE ROUTINE.
The new account is needed if the original user account contained a host mask.
A user account with a host mask is a distinct user account in this context.
An alternative would be to first get the most permissive user account which
include the current user connection and then assign privileges to that
account. This behavior change is considered out of scope for this bug patch.
The implicit assignment of privileges when a user creates a stored routine is a
considered to be a feature for user convenience and as such it is not
a critical operation. Any failure to complete this operation is thus considered
non-fatal (an error becomes a warning).
The patch back ports a stack implementation of the internal error handler interface.
This enables the use of multiple error handlers so that it is possible to intercept
and cancel errors thrown by lower layers. This is needed as a error handler already
is used in the call stack emitting the errors which needs to be converted.
The problem is that the internal variable used to specify a
transaction with consistent read was being used outside the
processing context of a START TRANSACTION WITH CONSISTENT
SNAPSHOT statement. The practical consequence was that a
consistent snapshot specification could leak to unrelated
transactions on the same session.
The solution is to ensure a consistent snapshot clause is
only relied upon for the START TRANSACTION statement.
This is already fixed in a similar way on 6.0.
mysql-test/r/consistent_snapshot.result:
Add test case result for Bug#44664
mysql-test/t/consistent_snapshot.test:
Add test case for Bug#44664
sql/sql_parse.cc:
The WITH CONSISTENT SNAPSHOT clause is only valid for the
START TRANSACTION statement.
The problem is that the internal variable used to specify a
transaction with consistent read was being used outside the
processing context of a START TRANSACTION WITH CONSISTENT
SNAPSHOT statement. The practical consequence was that a
consistent snapshot specification could leak to unrelated
transactions on the same session.
The solution is to ensure a consistent snapshot clause is
only relied upon for the START TRANSACTION statement.
This is already fixed in a similar way on 6.0.
routine does not exist
There is an inconsistency with DROP DATABASE IF EXISTS, DROP TABLE IF
EXISTS and DROP VIEW IF EXISTS: those are binlogged even if the DB or
TABLE does not exist, whereas DROP PROCEDURE IF EXISTS does not. It
would be nice or at least consistent if DROP PROCEDURE/STATEMENT
worked the same too.
Fixed DROP PROCEDURE|FUNCTION IF EXISTS by adding a call to
mysql_bin_log.write in mysql_execute_command. Checked also if all
documented "DROP (...) IF EXISTS" get binlogged.
NOTE: This is a 5.0 backport patch as requested by support.
mysql-test/r/rpl_drop_if_exists.result:
Result file for test case added.
mysql-test/r/rpl_sp.result:
Updated result file for existing test case that has now extra events in
binary log (the ones from drop if exists procedure/function).
mysql-test/t/rpl_drop_if_exists.test:
Added test case for asserting validity of proposed patch.
sql/sql_parse.cc:
Added call mysql_bin_log.write when lex has drop_if_exists enabled for
stored procedures.
routine does not exist
There is an inconsistency with DROP DATABASE IF EXISTS, DROP TABLE IF
EXISTS and DROP VIEW IF EXISTS: those are binlogged even if the DB or
TABLE does not exist, whereas DROP PROCEDURE IF EXISTS does not. It
would be nice or at least consistent if DROP PROCEDURE/STATEMENT
worked the same too.
Fixed DROP PROCEDURE|FUNCTION IF EXISTS by adding a call to
mysql_bin_log.write in mysql_execute_command. Checked also if all
documented "DROP (...) IF EXISTS" get binlogged.
NOTE: This is a 5.0 backport patch as requested by support.
The problem is that a SELECT .. FOR UPDATE statement might open
a table and later wait for a impeding global read lock without
noticing whether it is holding a table that is being waited upon
the the flush phase of the process that took the global read
lock.
The same problem also affected the following statements:
LOCK TABLES .. WRITE
UPDATE .. SET (update and multi-table update)
TRUNCATE TABLE ..
LOAD DATA ..
The solution is to make the above statements wait for a impending
global read lock before opening the tables. If there is no
impending global read lock, the statement raises a temporary
protection against global read locks and progresses smoothly
towards completion.
Important notice: the patch does not try to address all possible
cases, only those which are common and can be fixed unintrusively
enough for 5.0.
mysql-test/r/lock_multi.result:
Add test case result for Bug#43230
mysql-test/t/lock_multi.test:
Add test case for Bug#43230
sql/sql_lex.cc:
Initialize flag.
sql/sql_lex.h:
Add a flag to the lexer.
sql/sql_parse.cc:
Wait for the global read lock is a write lock is going to be
taken. The wait is done before opening tables.
sql/sql_yacc.yy:
Protect against the GRL if its a SELECT .. FOR UPDATE or LOCK TABLES
.. WRITE statement.
The problem is that a SELECT .. FOR UPDATE statement might open
a table and later wait for a impeding global read lock without
noticing whether it is holding a table that is being waited upon
the the flush phase of the process that took the global read
lock.
The same problem also affected the following statements:
LOCK TABLES .. WRITE
UPDATE .. SET (update and multi-table update)
TRUNCATE TABLE ..
LOAD DATA ..
The solution is to make the above statements wait for a impending
global read lock before opening the tables. If there is no
impending global read lock, the statement raises a temporary
protection against global read locks and progresses smoothly
towards completion.
Important notice: the patch does not try to address all possible
cases, only those which are common and can be fixed unintrusively
enough for 5.0.
