A new CMake option,
MYSQL_PROJECT_NAME, can be set on Windows or Mac OS X to be used in the project name. (Bug #13551687)
ucs2_general_mysql500_cicollations have been added that preserve the behavior of
ucs2_general_cifrom versions of MySQL previous to 5.1.24. Bug #27877 corrected an error in the original collations but introduced an incompatibility for columns that contain German
'ß'LATIN SMALL LETTER SHARP S. (As a result of the fix, that character compares equal to characters with which it previously compared different.) A symptom of the problem after upgrading to MySQL 5.1.24 or newer from a version older than 5.1.24 is that
CHECK TABLEproduces this error:
Table upgrade required. Please do "REPAIR TABLE `t`" or dump/reload to fix it!
REPAIR TABLEcould not fix the problem. The new collations permit older tables created before MySQL 5.1.24 to be upgraded to current versions of MySQL.
To convert an affected table after a binary upgrade that leaves the table files in place, alter the table to use the new collation. Suppose that the table
t1contains one or more problematic
utf8columns. To convert the table at the table level, use a statement like this:
ALTER TABLE t1 CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci;
To apply the change on a column-specific basis, use a statement like this (be sure to repeat the column definition as originally specified except for the
ALTER TABLE t1 MODIFY c1 CHAR(N) CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci;
To upgrade the table using a dump and reload procedure, dump the table using mysqldump, modify the
CREATE TABLEstatement in the dump file to use the new collation, and reload the table.
After making the appropriate changes,
CHECK TABLEshould report no error.
For more information, see Checking Whether Tables or Indexes Must Be Rebuilt, and Rebuilding or Repairing Tables or Indexes. (Bug #43593, Bug #11752408)
Performance; InnoDB: Memory allocation for
InnoDBtables was reorganized to reduce the memory overhead for large numbers of tables or partitions, avoiding situations where the “resident set size” could grow regardless of
FLUSH TABLESstatements. The problem was most evident for tables with large row size. Some of the memory that was formerly allocated for every open table is now allocated only when the table is modified for the first time. (Bug #11764622, Bug #57480)
Incompatible Change: An earlier change (in MySQL 5.1.59 and 5.5.16) was found to modify date-handling behavior in General Availability-status series (MySQL 5.1 and 5.5). This change has been reverted.
The change was that several functions became more strict when passed a
DATE()function value as their argument, thus they rejected incomplete dates with a day part of zero. These functions were affected:
YEARWEEK(). The previous behavior has been restored. (Bug #13458237)
InnoDB: A Valgrind error was fixed in the function
os_aio_init(). (Bug #13612811)
InnoDB: The server could crash when creating an
InnoDBtemporary table under Linux, if the
$TMPDIRsetting points to a
innodb_use_native_aiois enabled, as it is by default in MySQL 5.5.4 and higher. The entry in the error log looked like:
101123 2:10:59 InnoDB: Operating system error number 22 in a file operation. InnoDB: Error number 22 means 'Invalid argument'.
The crash occurred because asynchronous I/O is not supported on tmpfs in some Linux kernel versions. The workaround was to turn off the
innodb_use_native_aiosetting or use a different temporary directory. The fix causes
InnoDBto turn off the
innodb_use_native_aiosetting automatically if it detects that the temporary file directory does not support asynchronous I/O. (Bug #13593888, Bug #11765450, Bug #58421)
InnoDB: References to C preprocessor symbols and macros
UNIV_SET_MEM_TO_ZEROwere removed from the
InnoDBsource code. They were only used in debug builds instrumented for Valgrind. They are replaced by calls to the
UNIV_MEM_INVALID()macro. (Bug #13418934)
InnoDB: The MySQL server could halt with an assertion error:
InnoDB: Failing assertion: page_get_n_recs(page) > 1
Subsequent restarts could fail with the same error. The error occurred during a purge operation involving the
InnoDBchange buffer. The workaround was to set the configuration option
innodb_change_buffering=inserts. (Bug #13413535, Bug #61104)
InnoDB: With 1024 concurrent
InnoDBtransactions running concurrently and the
innodb_file_per_tablesetting enabled, a
CREATE TABLEoperation for an
InnoDBtable could fail. The
.ibdfile from the failed
CREATE TABLEwas left behind, preventing the table from being created later, after the load had dropped.
The fix adds error handling to delete the erroneous
.ibdfile. This error was less likely to occur in MySQL 5.5 and 5.6, because raising the number of
InnoDBundo slots increased the number of simultaneous transactions needed to trigger the bug, from 1K to 128K. (Bug #12400341)
InnoDB: When copying a partitioned
InnoDBtable from a Linux system to a Windows system, you could encounter this error:
101115 14:19:53 [ERROR] Table .\test\d has no primary key in InnoDB data dictionary, but has one in MySQL!
Normally, the solution to copy
InnoDBtables from Linux to Windows is to create the tables on Linux with the
lower_case_table_namesoption enabled. Partitioned tables, with
#P#appended to the filename, were not covered by that solution. (Bug #11765438, Bug #58406)
Replication: Executing mysqlbinlog with the
Nwas equal either to 0 or to a value greater than the length of the dump file, caused it to crash.
This issue was introduced in MySQL 5.5.18 by the fix for Bug #32228 and Bug #11747416. (Bug #13593869, Bug #64035)
Replication: It was possible on replication slaves where
FEDERATEDtables were in use to get timeouts on long-running operations, such as Error 1160 Got an error writing communication packets. The
FEDERATEDtables did not need to be replicated for the issue to occur. (Bug #11758931, Bug #51196)
References: See also Bug #12896628, Bug #61790.
Replication: On Windows replication slave hosts,
STOP SLAVEtook an excessive length of time to complete when the master was down. (Bug #11752315, Bug #43460)
The shared version of
libmysqlclientdid not export these functions for linking by client programs:
my_print_help(). (Bug #13604121)
A query that used an index on a
CHARcolumn referenced in a
BETWEENclause could return invalid results. (Bug #13463488, Bug #63437)
Expressions that compared a
BIGINTcolumn with any non-integer constant were performed using integers rather than decimal or float values, with the result that the constant could be truncated. This could lead to any such comparison that used
BETWEENyielding false positive or negative results. (Bug #13463415, Bug #11758543, Bug #63502, Bug #50756)
When the optimizer performed conversion of
DECIMALvalues while evaluating range conditions, it could produce incorrect results. (Bug #13453382)
When running mysqldump with both the
--flush-logsoptions, the flushing of the log performed an implicit
COMMIT(see Statements That Cause an Implicit Commit), causing more than one transaction to be used and thus breaking consistency. (Bug #12809202, Bug #61854)
It was possible in the event of successive failures for mysqld_safe to restart quickly enough to consume excessive amounts of CPU. Now, on systems that support the sleep and date system utilities, mysqld_safe checks to see whether it has restarted more than 5 times in the current second, and if so, waits 1 second before attempting another restart. (Bug #11761530, Bug #54035)
If an attempt to initiate a statement failed, the issue could not be reported to the client because it was not prepared to receive any error messages prior to the execution of any statement. Since the user could not execute any queries, they were simply disconnected without providing a clear error.
After the fix for this issue, the client is prepared for an error as soon as it attempts to initiate a statement, so that the error can be reported prior to disconnecting the user. (Bug #11755281, Bug #47032)
libmysql.dlllibrary was missing several symbols:
mysql_plugin_options. (Bug #69204, Bug #16797982, Bug #62394)
Using myisamchk with the sort recover method to repair a table having fixed-width row format could cause the row pointer size to be reduced, effectively resulting in a smaller maximum data file size. (Bug #48848, Bug #11756869)
The stored routine cache was subject to a small memory leak that over time or with many routines being used could result in out-of-memory errors.
The fix for this issue also introduces a new global server system variable
stored_program_cachewhich can be used for controlling the size of the stored routine cache. (Bug #44585, Bug #11753187)
Under some circumstances, the result of
SUBSTRING_INDEX()incorrectly depended on the contents of the previous row. (Bug #42404, Bug #11751514)