After BUG#36649, warnings for sub-statements are cleared when a
new sub-statement is started. This is problematic since it suppresses
warnings for unsafe statements in some cases. It is important that we
always give a warning to the client, because the user needs to know
when there is a risk that the slave goes out of sync.
We fixed the problem by generating warning messages for unsafe statements
while returning from a stored procedure, function, trigger or while
executing a top level statement.
We also started checking unsafeness when both performance and log tables are
used. This is necessary after the performance schema which does a distinction
between performance and log tables.
Fix by adding "DEPENDS gen_lex_hash" to ADD_CUSTOM_COMMAND(),
so it regenerates lex_hash.h whenever gen_lex_lash changes.
Also, make sql dependent on GenServerSource to avoid concurrent
generation of lex_hash.h (once for sql , and in parallel for embedded)
Restore the original behavior of check-cpu with respect to core2.
It isn't used as a actual target processor type, but as a mean to
perform other kinds of architecture checks.
- Simplify sql-bench installation,
do not try to resolve names : this leads to probem
if builddir is symlink located on different filesystem.
(reported by alik)
- Make WITHOUT_XXX (disabling plugin) work for DEFAULT
plugins. Prior to the patch is behaved just like
MANDATORY.
- LINK_LIBRARIES in MYSQL_ADD_PLUGIN had no effect for
statically linked plugins.
- Fix constant rebuild of initdb target on Windows.
if() treated any non-numeric string as false
Fixed to treat those as true instead
Added some test cases
Fixed missing $ in variable name in include/mix2.inc
******
This patch fixes the following bugs:
- Bug#5889: Exit handler for a warning doesn't hide the warning in
trigger
- Bug#9857: Stored procedures: handler for sqlwarning ignored
- Bug#23032: Handlers declared in a SP do not handle warnings generated
in sub-SP
- Bug#36185: Incorrect precedence for warning and exception handlers
The problem was in the way warnings/errors during stored routine execution
were handled. Prior to this patch the logic was as follows:
- when a warning/an error happens: if we're executing a stored routine,
and there is a handler for that warning/error, remember the handler,
ignore the warning/error and continue execution.
- after a stored routine instruction is executed: check for a remembered
handler and activate one (if any).
This logic caused several problems:
- if one instruction generates several warnings (errors) it's impossible
to choose the right handler -- a handler for the first generated
condition was chosen and remembered for activation.
- mess with handling conditions in scopes different from the current one.
- not putting generated warnings/errors into Warning Info (Diagnostic
Area) is against The Standard.
The patch changes the logic as follows:
- Diagnostic Area is cleared on the beginning of each statement that
either is able to generate warnings, or is able to work with tables.
- at the end of a stored routine instruction, Diagnostic Area is left
intact.
- Diagnostic Area is checked after each stored routine instruction. If
an instruction generates several condition, it's now possible to take a
look at all of them and determine an appropriate handler.
This is a null merge of the InnoDB changesets which get to trunk
by manual porting and committing into mysql-trunk-innodb and then
merging into mysql-trunk-bugfixing.
