crashes MySQL 5.122
There was a difference in how UNIONs are handled
on top level and when in sub-query.
Because the rules for sub-queries were syntactically
allowing cases that are not currently supported by
the server we had crashes (this bug) or wrong results
(bug 32051).
Fixed by making the syntax rules for UNIONs match the
ones at top level.
These rules however do not support nesting UNIONs, e.g.
(SELECT a FROM t1 UNION ALL SELECT b FROM t2)
UNION
(SELECT c FROM t3 UNION ALL SELECT d FROM t4)
Supports for statements with nested UNIONs will be
added in a future version.
strmake() calls are easy to get wrong. Add checks in extra
debug mode to identify possible exploits.
Remove some dead code.
Remove some off-by-one errors identified with new checks.
Problems:
1. looking for a matching partition we miss the fact that the maximum
allowed value is in the PARTITION p LESS THAN MAXVALUE.
2. one can insert maximum value if numeric maximum value is the last range.
(should only work if LESS THAN MAXVALUE).
3. one cannot have both numeric maximum value and MAXVALUE string as ranges
(the same value, but different meanings).
Fix: consider the maximum value as a supremum.
The client program 'mysqlbinlog' crashed when trying to print a User_var_log_event holding
a floating-point value since the format specifier for my_b_printf() does not support
floating-point format specifiers.
This patch prints the floating-point number to an internal buffer, and then writes
that buffer to the output instead.
The crash happens because we change share->partition_info where 'share' is global struct
(it affects other threads which use the same 'share').
It causes discrepancy between 'share' and handler data.
The fix:
Move share->partition_info update into WFRM_INSTALL_SHADOW part which is protected by OPEN_lock.
Problem:
The "Slave I/O thread couldn't register on master" error sporadically
occurred in replication tests because the slave I/O thread got
killed by STOP SLAVE before or while registering on master.
Fixed by checking the state of the I/O thread, and issueing
the error only if it was not explicitely killed by a user.
FLUSH TABLES WITH READ LOCK fails to properly detect write locked
tables when running under low priority updates.
The problem is that when trying to aspire a global read lock, the
reload_acl_and_cache() function fails to properly check if the thread
has a low priority write lock, which later my cause a server crash or
deadlock.
The solution is to simple check if the thread has any type of the
possible exclusive write locks.
is_last_prefix <= 0, file .\opt_range.cc.
SELECT ... GROUP BY bit field failed with an assertion if the
bit length of that field was not divisible by 8.
Problem: setting Item_func_rollup_const::null_value property to argument's null_value
before (without) the argument evaluation may result in a crash due to wrong null_value.
Fix: use is_null() to set Item_func_rollup_const::null_value instead as it evaluates
the argument if necessary and returns a proper value.
The patch I previously pushed for this bug did not compile because
a field in class THD had been renamed.
This patch renames thd->query_error to thd->is_slave_error in
log_event_old.cc by applying the same patch to log_event_old.cc as
was previously applied to log_event.cc.
Problem: even if an Item_xml_str_func successor returns NULL, it doesn't have
a corresponding property (maybe_null) set, that leads to a failed assertion.
Fix: set nullability property of Item_xml_str_func.
Index lookup does not always guarantee that we can
simply remove the relevant conditions from the WHERE
clause. Reasons can be e.g. conversion errors,
partial indexes etc.
The optimizer was removing these parts of the WHERE
condition without any further checking.
This leads to "false positives" when using indexes.
Fixed by checking the index reference conditions
(using WHERE) when using indexes with sub-queries.
Problem: we have CHECK TABLE options allowed (by accident?) for
ANALYZE/OPTIMIZE TABLE.
Fix: disable them.
Note: it might require additional fixes in 5.1/6.0
Problem: caching 00000000-00000099 dates as integer values we're
improperly shifting them up twice in the get_datetime_value().
Fix: don't shift cached DATETIME values up for the second time.
