yaSSL was upgraded from version 1.7.2 to 2.2.0. (Bug #13706828)
References: See also Bug #13713205.
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)
Security Fix: A security bug was fixed. (Bug #63775)
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)
Important Change; InnoDB: When a row grew in size due to an
UPDATEoperation, other (non-updated) columns could be moved to off-page storage so that information about the row still fit within the constraints of the
InnoDBpage size. The pointer to the new allocated off-page data was not set up until the pages were allocated and written, potentially leading to lost data if the system crashed while the column was being moved out of the page. The problem was more common with tables using
ROW_FORMAT=COMPRESSEDalong with the Barracuda file format, particularly with the
innodb_file_per_tablesetting enabled, because page allocation operations are more common as the
.ibdtablespace files are extended. Still, the problem could occur with any combination of InnoDB version, file format, and row format.
A related issue was that during such an
UPDATEoperation, or an
INSERToperation that reused a delete-marked record, other transactions could see invalid data for the affected column, regardless of isolation level.
The fix corrects the order of operations for moving the column data off the original page and replacing it with a pointer. Now if a crash occurs at the precise moment when the column data is being transferred, the transfer will not be re-run during crash recovery.
In MySQL 5.1, this fix applies to the InnoDB Plugin, but not the built-in InnoDB storage engine. (Bug #13721257, Bug #12612184, Bug #12704861)
InnoDB: An erroneous assertion could occur, in debug builds only, when creating an index on a column containing zero-length values (that is,
''). (Bug #13654923)
InnoDB: A DDL operation such as
ALTER TABLE ... ADD COLUMNcould stall, eventually timing out with an
Error 1005: Can't create tablemessage referring to
fil_rename_tablespace. (Bug #13636122, Bug #62100, Bug #63553)
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: A DDL operation for an
InnoDBtable could cause a busy MySQL server to halt with an assertion error:
InnoDB: Failing assertion: trx->error_state == DB_SUCCESS
The error occurred if the DDL operation was run while all 1023 undo slots were in use by concurrent transactions. 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 (corresponding to the number of undo slots) from 1K to 128K. (Bug #12739098, Bug #62401)
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)
InnoDB: Server startup could produce an error for temporary tables using the
InnoDBstorage engine, if the path in the
$TMPDIRvariable ended with a
/character. The error log would look like:
120202 19:21:26 InnoDB: Operating system error number 2 in a file operation. InnoDB: The error means the system cannot find the path specified. InnoDB: If you are installing InnoDB, remember that you must create InnoDB: directories yourself, InnoDB does not create them. 120202 19:21:26 InnoDB: Error: trying to open a table, but could not InnoDB: open the tablespace file './t/#sql7750_1_0.ibd'! InnoDB: Have you moved InnoDB .ibd files around without using the InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE? InnoDB: It is also possible that this is a temporary table #sql..., InnoDB: and MySQL removed the .ibd file for this.
The workaround for the problem was to create a similar temporary table again, copy its
tmpdirunder the name mentioned in the error message (for example,
#sql123.frm) and restart
tmpdirset to its normal value without a trailing slash, for example
/var/tmp. On startup, MySQL would see the
.frmfile and issue
DROP TABLEfor the orphaned temporary table. (Bug #11754376, Bug #45976)
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.
yaSSL fixes previously applied to MySQL 5.5 were backported to 5.0 and 5.1. (Bug #13706621)
A query that used an index on a
CHARcolumn referenced in a
BETWEENclause could return invalid results. (Bug #13463488, Bug #63437)
When the optimizer performed conversion of
DECIMALvalues while evaluating range conditions, it could produce incorrect results. (Bug #13453382)
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)
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)
Under some circumstances, the result of
SUBSTRING_INDEX()incorrectly depended on the contents of the previous row. (Bug #42404, Bug #11751514)
Due to improper locking, concurrent inserts into an
ARCHIVEtable at the same time as repair and check operations on the table resulted in table corruption. (Bug #37280, Bug #11748748)