* Guangbao Ni <gni@stripped> [09/03/12 16:21]:
> 2846 Guangbao Ni 2009-03-12
> BUG#42640 mysqld crashes when unsafe statements are executed
> (STRICT_TRANS_TABLES mode)
The current implementation of the strict mode is an
oversimplification: there is no such thing in the SQL standard as
elevation of all warnings to errors.
Certain conditions are always errors, and certain are always
warnings.
This oversimplification is the root cause of the grievance
manifested in 42640..
A way to implement the standard semantics in case of
ER_BINLOG_UNSAFE_STATEMENT is to temporarily save and reset
thd->abort_on_warning when reporting this warning:
save_thd_abort_on_warning= thd->abort_on_warning;
thd->abort_on_warning= 0;
push_warning(ER_BINLOG_UNSAFE_STATEMENT);
thd->abort_on_warning= save_thd_abort_on_warning;
Alternatively, to not involve juggling with thd members,
one could add a flag to push_warning() that would force it to
ignore the strict mode.
The final and ultimate solution should let one specify
push_warning behaviour in regard to strict mode in description of
the warning itself, in share/errmsg.txt.
The solution in this patch is doing more than the situation
demands: it will clear any warning that happens to be in the
diagnostics area, not just the offensive one, and thus can mask
future programming errors.
Please consider one of the solutions suggested above.
> === modified file 'sql/sql_class.cc'
> --- a/sql/sql_class.cc 2009-03-09 11:15:46 +0000
> +++ b/sql/sql_class.cc 2009-03-12 18:10:28 +0000
> @@ -3677,6 +3677,14 @@ int THD::binlog_query(THD::enum_binlog_q
> MYSQL_ERRMSG_SIZE, query_arg);
> binlog_flags|= BINLOG_FLAG_UNSAFE_STMT_PRINTED;
> }
> + /*
> + A warning can be elevated a error when STRICT sql mode.
> + But we don't want to elevate binlog warning to error here.
> + */
> + if (is_error())
> + {
> + clear_error();
> + }
> }
Thanks,
--
kostja
