Fix parsing of mysql client commands, especially in relation to
single-line comments when --comments was specified.
This is a little tricky, because we need to allow single-line
comments in the middle of statements, but we don't want to allow
client commands in the middle of statements. So in
comment-preservation mode, we go ahead and send single-line
comments to the server immediately when we encounter them on their
own.
This is still slightly flawed, in that it does not handle a
single-line comment with leading spaces, followed by a client-side
command when --comment has been enabled. But this isn't a new
problem, and it is quite an edge condition. Fixing it would require
a more extensive overall of how the mysql client parses commands.
Bug#37671 crash on prepared statement + cursor + geometry + too many open files!
if mysql_execute_command() returns error then free materialized_cursor object.
is_rnd_inited is added to satisfy rnd_end() assertion
(handler may be uninitialized in some cases)
Removed values with more than 15 significant digits from the test case. Results of
reading/printing such values using system library functions depend on implementation
and thus are not portable.
Bug #41173 rpl_packet fails sporadically on pushbuild: query 'DROP TABLE t1' failed
The both issues appeared to be a race between the SQL thread executing CREATE table t1
and the IO thread that is expected to stop at the consequent big size event.
The two events need serialization which is implemented.
The early bug required back-porting a part fixes for bug#38350 exclusively for 5.0 version.
BUG#39325 Server crash inside MYSQL_LOG::purge_first_log halts replicaiton
The patch reverses the order of the purging and updating events for log and relay-log.info/index files respectively.
This solves the problem of having holes caused by crashes happening between updating info/index files and purging logs.
NOTE: This is a combined patch for BUG#38826 and BUG#39325. This patch is based on bugteam tree and takes into account reviewers suggestions.
bigint' fails on windows.
Visual Studio does not take into account some x86 hardware limitations
which leads to incorrect results when converting large DOUBLE values
to BIGINT UNSIGNED ones.
Fixed by adding a workaround for double->ulonglong conversion on
Windows.
Updated MySQL time handling code to react correctly on UTC leap second additions.
MySQL functions that return the OS current time, like e.g. CURDATE(), NOW() etc
will return :59:59 instead of :59:60 or 59:61.
As a result the reader will receive :59:59 for 2 or 3 consecutive seconds
during the leap second.
This fix will not affect the values returned by UNIX_TIMESTAMP() for leap seconds.
But note that when converting the value returned by UNIX_TIMESTAMP() to broken
down time the correction of leap seconds will still be applied.
Note that this fix will make a difference *only* if the OS is specially configured
to return leap seconds from the OS time calls or when using a MySQL time zone
defintion that has leap seconds.
Even after this change date/time literals (or other broken down time
representations) with leap seconds (ending on :59:60 or 59:61) will still be
considered illegal and discarded by the server with an error or
a warning depending on the sql mode.
Added a test case to demonstrate the effect of the fix.
TABLE_LIST doesn't free Strings in its string lists
(TABLE_LIST::use_index and TABLE_liST::ignore_index), so
calling c_ptr_safe() on that Strings leads to memleaks.
OTOH "safe" c_ptr_safe() is not necessary there and we can
replace it with c_ptr().
an error
Even after the fix for bug 28701 visible behaviors of
SELECT FROM a view and SELECT FROM a regular table are
little bit different:
1. "SELECT FROM regular table USE/FORCE/IGNORE(non
existent index)" fails with a "ERROR 1176 (HY000):
Key '...' doesn't exist in table '...'"
2. "SELECT FROM view USING/FORCE/IGNORE(any index)" fails
with a "ERROR 1221 (HY000): Incorrect usage of
USE/IGNORE INDEX and VIEW". OTOH "SHOW INDEX FROM
view" always returns empty result set, so from the point
of same behaviour view we trying to use/ignore non
existent index.
To harmonize the behaviour of USE/FORCE/IGNORE(index)
clauses in SELECT from a view and from a regular table the
"ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
and VIEW" message has been replaced with the "ERROR 1176
(HY000): Key '...' doesn't exist in table '...'" message
like for tables and non existent keys.
The SHOW VARIABLES LIKE .../SELECT @@/SELECT ... FROM INFORMATION_SCHEMA.VARIABLES
were assuming that all the system variables are in system charset (UTF-8).
However the variables that are settable through command line will have a different
character set (character_set_filesystem).
Fixed the server to remember the correct character set of basedir, datadir, tmpdir,
ssl, plugin_dir, slave_load_tmpdir, innodb variables; init_connect and init_slave
variables and use it when processing data.
The bug is repeatable with latest(1.0.1) InnoDB plugin on Linux, Win,
If MySQL is compiled with valgrind there are errors about
using of uninitialized variable(orig_table).
The fix is to set field->orig_table correct value.
enable uncacheable flag if we update a view with check option
and check option has a subselect, otherwise, the check option
can be evaluated after the subselect was freed as independent
(See full_local in JOIN::join_free())
