branches/5.0 bug#39483 InnoDB hang on adaptive hash because of out
of order ::open() call by MySQL
Under some conditions MySQL calls ::open with search_latch leading
to a deadlock as we try to acquire dict_sys->mutex inside ::open
breaking the latching order. The fix is to release search_latch.
Reviewed by: Heikki
This fixes Bug#36149: Read buffer overflow in srv0start.c found during "make
test"
Per-revision comments:
r2484 | vasil | 2008-05-28 15:32:48 +0300 (Wed, 28 May 2008) | 9 lines
Fix Bug#36149 Read buffer overflow in srv0start.c found during "make test"
Use strncmp(3) instead of memcmp(3) to avoid reading past end of the string
if it is empty (*str == '\0'). This bug is _not_ a buffer overflow.
Discussed with: Sunny (via IM)
r2538 | inaam | 2008-07-15 21:24:02 +0300 (Tue, 15 Jul 2008) | 15 lines
Fix of issue# 4
Fixed a timing hole where a thread dropping an index can free the
in-memory index struct while another thread is still using
that structure to remove entries from adaptive hash index belonging
to one of the pages that belongs to the index being dropped.
The fix is to have a reference counter in the index struct and to
wait for this counter to drop to zero beforing freeing the struct.
Reviewed by: Heikki
r2544 | inaam | 2008-07-22 18:58:11 +0300 (Tue, 22 Jul 2008) | 8 lines
Removed UNIV_INLINE qualifier from btr_search_info_get_ref_count().
Otherwise compilation failed on non-debug builds.
Pointed by: Vasil
not handle errors from gettimeofday".
r2475 | vasil | 2008-05-22 19:35:30 +0300 (Thu, 22 May 2008) | 13 lines
Fix by retrying gettimeofday() several times if it fails in ut_usectime().
If it fails on all calls then return error to the caller to be handled
at higher level.
Update the variable innodb_row_lock_time_max in SHOW STATUS output only
if ut_usectime() was successful.
IF(..., CAST(longtext AS UNSIGNED), signed_val)
(was: LEFT JOIN on inline view crashes server)
Select from a LONGTEXT column wrapped with an expression
like "IF(..., CAST(longtext_column AS UNSIGNED), smth_signed)"
failed an assertion or crashed the server. IFNULL function was
affected too.
LONGTEXT column item has a maximum length of 32^2-1 bytes,
at the same time this is a maximum possible length of any
MySQL item. CAST(longtext_column AS UNSIGNED) returns some
unsigned numeric result of length 32^2-1, so the result of
IF/IFNULL function of this number and some other signed number
will have text length of (32^2-1)+1=32^2 (one byte for the
minus sign) - there is integer overflow, and the length is
equal to zero. That caused assert/crash.
CAST AS UNSIGNED function has been modified to limit maximal
length of resulting number to 67 (maximal length of DECIMAL
and two characters for minus sign and dot).
mysql-test/r/func_if.result:
Added test case for bug #40761.
mysql-test/t/func_if.test:
Added test case for bug #40761.
sql/item_func.h:
Bug #40761: Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
CAST AS UNSIGNED function has been modified to limit maximal
length of resulting number to 67 (maximal length of DECIMAL
and two characters for minus sign and dot).
IF(..., CAST(longtext AS UNSIGNED), signed_val)
(was: LEFT JOIN on inline view crashes server)
Select from a LONGTEXT column wrapped with an expression
like "IF(..., CAST(longtext_column AS UNSIGNED), smth_signed)"
failed an assertion or crashed the server. IFNULL function was
affected too.
LONGTEXT column item has a maximum length of 32^2-1 bytes,
at the same time this is a maximum possible length of any
MySQL item. CAST(longtext_column AS UNSIGNED) returns some
unsigned numeric result of length 32^2-1, so the result of
IF/IFNULL function of this number and some other signed number
will have text length of (32^2-1)+1=32^2 (one byte for the
minus sign) - there is integer overflow, and the length is
equal to zero. That caused assert/crash.
The bug has been fixed by the same solution as in the CASE
function implementation.
mysql-test/r/func_if.result:
Added test case for bug #40761.
mysql-test/t/func_if.test:
Added test case for bug #40761.
sql/item_cmpfunc.cc:
Bug #40761: Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
1. Item_func_case::agg_str_lengths method has been moved
to the Item_func superclass.
2. Item_func_ifnull/Item_func_if::fix_length_and_dec methods
have been updated to calculate max_length, decimals and
unsigned flag like Item_func_case.
sql/item_cmpfunc.h:
Bug #40761: Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
Item_func_case::agg_str_lengths method has been moved to
the Item_func superclass.
sql/item_func.cc:
Bug #40761: Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
Item_func_case::agg_str_lengths method has been moved to
the Item_func superclass.
sql/item_func.h:
Bug #40761: Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
Item_func_case::agg_str_lengths method has been moved to
the Item_func superclass.
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)
sql/sql_cursor.cc:
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)
sql/sql_select.cc:
added result check
tests/mysql_client_test.c:
test case
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.
mysql-test/r/type_float.result:
Removed values with more than 15 significant digits from the test case.
mysql-test/t/type_float.test:
Removed values with more than 15 significant digits from the test case.
if table has bit fields then uneven bits(if exist) are stored into null bits place.
So we need to copy null bits in case of uneven bit field presence.
mysql-test/r/type_bit.result:
test result
mysql-test/t/type_bit.test:
test case
sql/sql_select.cc:
if table has bit fields then uneven bits(if exist) are stored into null bits place.
So we need to copy null bits in case of uneven bit field presence.
added ability for TINY[MEDIUM] text fields
to be converted to greater subtype during
alter if necessary(altered charset)
mysql-test/r/alter_table.result:
test result
mysql-test/t/alter_table.test:
test case
sql/sql_table.cc:
added ability for TINY[MEDIUM] text fields
to be converted to greater subtype during
alter if necessary(altered charset)
the problem: FORMAT func max_length value was calculated incorrectly
the fix: correct calculation of max_length
mysql-test/r/func_str.result:
test result
mysql-test/t/func_str.test:
test case
sql/item_strfunc.h:
the problem: FORMAT func max_length value was calculated incorrectly
the fix: correct calculation of max_length
show default value for BIT field in printable format
mysql-test/r/type_bit.result:
Bug#35796 SHOW CREATE TABLE and default value for BIT field
test result
mysql-test/t/type_bit.test:
Bug#35796 SHOW CREATE TABLE and default value for BIT field
test case
sql/item.cc:
Bug#35796 SHOW CREATE TABLE and default value for BIT field
issue an error if BIN|HEX deafult value is empty value
(behaviour like for INT fields)
The reason for the failures was bug #21205 (fixed in 6.0 by dtoa, but still present in 5.0/5.1).
mysql-test/r/type_float.result:
Modified the failing test case so that bug #21205 does not occur.
mysql-test/t/type_float.test:
Modified the failing test case so that bug #21205 does not occur.
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.
mysql-test/r/rpl_packet.result:
results changed due to bug#33420, bug#41173.
mysql-test/t/rpl_packet.test:
adding synchronization for sql and io thread (bug#41173 problem).
simplifying the output to show only a relevant info (5.0 sole problem bug#33420).
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.
include/config-win.h:
Added double2ulonglong(double) function implementing a workaround for
broken double->ulonglong conversion on Windows/x86.
include/my_global.h:
Define double2ulonglong() as a simple typecast for anything but
Windows.
mysql-test/r/type_float.result:
Added a test case for bug #27483.
mysql-test/t/type_float.test:
Added a test case for bug #27483.
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.
mysql-test/r/timezone3.result:
Bug #39920: test case
mysql-test/std_data/Moscow_leap:
Bug #39920: updated the Moscow time zone to Dr. Olson's tzdata 2008i
to accomodate for the 2008 leap second
mysql-test/t/timezone3.test:
Bug #39920: test case
sql/tztime.cc:
Bug #39920: adjust leap seconds (:60 or :61) to :59
sql/tztime.h:
Bug #39920: adjust leap seconds (:60 or :61) to :59
by using and taking out a full path.
mysql-test/r/ctype_filesystem.result:
Bug #37399: use MYSQL_TEST_DIR rooted test
mysql-test/t/ctype_filesystem-master.opt:
Bug #37399: use MYSQL_TEST_DIR rooted test
mysql-test/t/ctype_filesystem.test:
Bug #37399: use MYSQL_TEST_DIR rooted test
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.
mysql-test/r/view.result:
Added test case for bug #33461.
Updated test case for bug 28701.
mysql-test/t/view.test:
Added test case for bug #33461.
Updated test case for bug 28701.
sql/sql_view.cc:
Bug #33461: SELECT ... FROM <view> USE INDEX (...) throws
an error
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.
mysql-test/r/ctype_filesystem.result:
Bug #37339: test case (should be in utf-8)
mysql-test/t/ctype_filesystem-master.opt:
Bug #37339: test case (should be in ISO-8859-1)
mysql-test/t/ctype_filesystem.test:
Bug #37339: test case
sql/mysqld.cc:
Bug #37339: remember the correct character set for init_slave and init_connect
sql/set_var.cc:
Bug #37339:
- remember the character set of the relevant variables
- implement storing and using the correct
character set
sql/set_var.h:
Bug #37339: implement storing and using the correct
character set
sql/sql_show.cc:
Bug #37339: implement storing and using the correct
character set
