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.
A transaction could result in having an extra event after a query that
errored e.g because of a dup key. Such a query is rolled back in
innodb, as specified, but has not been in binlog.
It appeares that the binlog engine did not always register for a query
(statement) because the previous query had not reset at its statement
commit time. Because of that fact there was no roll-back to the
trx_data->before_stmt_pos position and a the pending event of the
errorred query could become flushed to the binlog file.
Fixed with deploying the reset of trx_data->before_stmt_pos at the end
of the query processing.
The "show status" may be received by the server in a startup state, where it only can reject the statement, so that the client then react with 2013.
So, adding 2013 to the list of errors may help, as the "show status" will be repeated then.
The non documented command 'ALTER PARTITION t REORGANIZE PARTITION'
(without any partitions!) which only make sense for nativly
partitioned engines, such as NDB, crashes the server if there was
no change of number of partitions.
The problem was wrong usage of fast_end_partition function,
which led to usage of a non initialized variable.
The minimum value differs depending on the OS and mysqld build, so that the test fail spradically.
The check of this value has been changed from check of concrete values to the check of a range that is near by the expected value.
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.
which were determined by the server depending on the os. The solution is to disable warnings in general.
The check of the values only have been done for Linux and Windows. Now, the check has been changed to the check of
ranges (not more concrete values) being near by the expected (set) values.
column
When the storage engine uses secondary keys clustered with the primary key MySQL was
adding the primary key parts to each secondary key.
In doing so it was not checking whether the index was on full columns and this
resulted in the secondary keys being added to the list of covering keys even if
they have partial columns.
Fixed by not adding a primary key part to the list of columns that can be used
for index read of the secondary keys when the primary key part is a partial key part.
leads to an assertion failure
Any run-time error in stored function (like recursive function
call or update of table that is already updating by statement
which invoked this stored function etc.) that was used in some
expression of the single-table UPDATE statement caused an
assertion failure.
Multiple-table UPDATE (as well as INSERT and both single- and
multiple-table DELETE) are not affected.
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.
- disable the test suffering from Bug#41098 Query Cache returns wrong result with
concurrent insert
- additional improvements
Details:
- Move the test for the historic bug
Bug 28249 Query Cache returns wrong result with concurrent insert / certain lock
into its own testscript query_cache_28249.test.
- query_cache.test:
- replace error numbers with error names
- remove trailing spaces, replace tabs with spaces
- reset of @@global.log_bin_trust_function_creators to its original value
at the end of the test
- query_cache_28249.test:
- replace sleep 5 with poll routine
- avoid random differences caused by concurrent_inserts effects
- improved comments and formatting
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.
Reason for the failing test was that "SELECT count(*) from mysql.general_log;" was not always
the same number. That was fixed by "...count(*)>4..." as the minimal fulfilled condition.
As Bug 35371 was fixed the testcase with "log_output = 'FILE'" was enabled and changed to have
always the same result.
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())
