MySQL 歷史版本列表 Page45

更新時間：2012-03-26
更新細節：

What's new in this version:

Functionality Added or Changed:
- yaSSL was upgraded from version 1.7.2 to 2.2.0. 

Bugs Fixed:
- Security Fix: Bug #13510739 and Bug #63775 were fixed.
- 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: CONVERT_TZ(), DATE_ADD(), DATE_SUB(), DAYOFYEAR(), LAST_DAY(), TIMESTAMPDIFF(), TO_DAYS(), TO_SECONDS(), WEEK(), WEEKDAY(), WEEKOFYEAR(), YEARWEEK(). The previous behavior has been restored. 
- Important Change: InnoDB Storage Engine: When a row grew in size due to an UPDATE operation, other (non-updated) columns could be moved to off-page storage so that information about the row still fit within the constraints of the InnoDB page 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=DYNAMIC or ROW_FORMAT=COMPRESSED along with the Barracuda file format, particularly with the innodb_file_per_table setting enabled, because page allocation operations are more common as the .ibd tablespace 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 UPDATE operation, or an INSERT operation 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. 
- InnoDB Storage Engine: 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 Storage Engine: A DDL operation such as ALTER TABLE ... ADD COLUMN could stall, eventually timing out with an Error 1005: Can't create table message referring to fil_rename_tablespace. 
- InnoDB Storage Engine: References to C preprocessor symbols and macros HAVE_purify, UNIV_INIT_MEM_TO_ZERO, and UNIV_SET_MEM_TO_ZERO were removed from the InnoDB source code. They were only used in debug builds instrumented for Valgrind. They are replaced by calls to the UNIV_MEM_INVALID() macro. 
- InnoDB Storage Engine: A DDL operation for an InnoDB table 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 InnoDB undo slots increased the number of simultaneous transactions (corresponding to the number of undo slots) from 1K to 128K. 
- InnoDB Storage Engine: With 1024 concurrent InnoDB transactions running concurrently and the innodb_file_per_table setting enabled, a CREATE TABLE operation for an InnoDB table could fail. The .ibd file from the failed CREATE TABLE was left behind, preventing the table from being created later, after the load had dropped. The fix adds error handling to delete the erroneous .ibd file. This error was less likely to occur in MySQL 5.5 and 5.6, because raising the number of InnoDB undo slots increased the number of simultaneous transactions needed to trigger the bug, from 1K to 128K. 
- InnoDB Storage Engine: When copying a partitioned InnoDB table from a Linux system to a Windows system, you could encounter this error: 101115 14:19:53 [ERROR] Table . estd has no primary key in InnoDB data dictionary, but has one in MySQL! Normally, the solution to copy InnoDB tables from Linux to Windows is to create the tables on Linux with the lower_case_table_names option enabled. Partitioned tables, with #P# appended to the filename, were not covered by that solution. 
- InnoDB Storage Engine: Server startup could produce an error for temporary tables using the InnoDB storage engine, if the path in the $TMPDIR variable 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 .frm file to tmpdir under the name mentioned in the error message (for example, #sql123.frm) and restart mysqld with tmpdir set to its normal value without a trailing slash, for example /var/tmp. On startup, MySQL would see the .frm file and issue DROP TABLE for the orphaned temporary table. 
- A query that used an index on a CHAR column referenced in a BETWEEN clause could return invalid results. 
- When the optimizer performed conversion of DECIMAL values while evaluating range conditions, it could produce incorrect results. 
- When used with the --xml option, mysqldump --routines failed to dump any stored routines, triggers, or events. 
- It was possible on replication slaves where FEDERATED tables were in use to get timeouts on long-running operations, such as Error 1160 Got an error writing communication packets. The FEDERATED tables did not need to be replicated for the issue to occur. 
- 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. 
- 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. 
- Due to improper locking, concurrent inserts into an ARCHIVE table at the same time as repair and check operations on the table resulted in table corruption.

更新時間：2012-03-26
更新細節：

What's new in this version:

Functionality Added or Changed:
- InnoDB Storage Engine: A deprecation warning is now issued when --ignore-builtin-innodb is used. 
- yaSSL was upgraded from version 1.7.2 to 2.2.0.

Bugs Fixed:
- Important Change: InnoDB Storage Engine: When a row grew in size due to an UPDATE operation, other (non-updated) columns could be moved to off-page storage so that information about the row still fit within the constraints of the InnoDB page 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=DYNAMIC or ROW_FORMAT=COMPRESSED along with the Barracuda file format, particularly with the innodb_file_per_table setting enabled, because page allocation operations are more common as the .ibd tablespace 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 UPDATE operation, or an INSERT operation 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. 
- InnoDB Storage Engine: An erroneous assertion could occur, in debug builds only, when creating an index on a column containing zero-length values (that is, ''). 
- InnoDB Storage Engine: A DDL operation such as ALTER TABLE ... ADD COLUMN could stall, eventually timing out with an Error 1005: Can't create table message referring to fil_rename_tablespace. 
- InnoDB Storage Engine: A DDL operation for an InnoDB table 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 InnoDB undo slots increased the number of simultaneous transactions (corresponding to the number of undo slots) from 1K to 128K. 
- InnoDB Storage Engine: Server startup could produce an error for temporary tables using the InnoDB storage engine, if the path in the $TMPDIR variable 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 .frm file to tmpdir under the name mentioned in the error message (for example, #sql123.frm) and restart mysqld with tmpdir set to its normal value without a trailing slash, for example /var/tmp. On startup, MySQL would see the .frm file and issue DROP TABLE for the orphaned temporary table. 
- Replication: Statements that wrote to tables with AUTO_INCREMENT columns based on an unordered SELECT from another table could lead to the master and the slave going out of sync, as the order in which the rows are retrieved from the table may differ between them. Such statements include any INSERT ... SELECT, REPLACE ... SELECT, or CREATE TABLE ... SELECT statement. Such statements are now marked as unsafe for statement-based replication, which causes the execution of one to throw a warning, and forces the statement to be logged using the row-based format if the logging format is MIXED. 
- The contents of the shared and shared-compat RPM packages had been changed in versions 5.5.6 and 5.6.1 to avoid the overlap which they traditionally had (and still have in MySQL 5.0 and 5.1). However, the RPM meta information had not been changed in accordance, and so RPM still assumed a conflict between shared and shared-compat RPM packages. This has been fixed. 
- myisam_sort_buffer_size could not be set larger than 4GB on 64-bit systems. 
- Due to improper locking, concurrent inserts into an ARCHIVE table at the same time as repair and check operations on the table resulted in table corruption.

更新時間：2012-03-26
更新細節：

What's new in this version:

Functionality Added or Changed:
- InnoDB Storage Engine: A deprecation warning is now issued when --ignore-builtin-innodb is used. 
- yaSSL was upgraded from version 1.7.2 to 2.2.0.

Bugs Fixed:
- Important Change: InnoDB Storage Engine: When a row grew in size due to an UPDATE operation, other (non-updated) columns could be moved to off-page storage so that information about the row still fit within the constraints of the InnoDB page 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=DYNAMIC or ROW_FORMAT=COMPRESSED along with the Barracuda file format, particularly with the innodb_file_per_table setting enabled, because page allocation operations are more common as the .ibd tablespace 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 UPDATE operation, or an INSERT operation 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. 
- InnoDB Storage Engine: An erroneous assertion could occur, in debug builds only, when creating an index on a column containing zero-length values (that is, ''). 
- InnoDB Storage Engine: A DDL operation such as ALTER TABLE ... ADD COLUMN could stall, eventually timing out with an Error 1005: Can't create table message referring to fil_rename_tablespace. 
- InnoDB Storage Engine: A DDL operation for an InnoDB table 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 InnoDB undo slots increased the number of simultaneous transactions (corresponding to the number of undo slots) from 1K to 128K. 
- InnoDB Storage Engine: Server startup could produce an error for temporary tables using the InnoDB storage engine, if the path in the $TMPDIR variable 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 .frm file to tmpdir under the name mentioned in the error message (for example, #sql123.frm) and restart mysqld with tmpdir set to its normal value without a trailing slash, for example /var/tmp. On startup, MySQL would see the .frm file and issue DROP TABLE for the orphaned temporary table. 
- Replication: Statements that wrote to tables with AUTO_INCREMENT columns based on an unordered SELECT from another table could lead to the master and the slave going out of sync, as the order in which the rows are retrieved from the table may differ between them. Such statements include any INSERT ... SELECT, REPLACE ... SELECT, or CREATE TABLE ... SELECT statement. Such statements are now marked as unsafe for statement-based replication, which causes the execution of one to throw a warning, and forces the statement to be logged using the row-based format if the logging format is MIXED. 
- The contents of the shared and shared-compat RPM packages had been changed in versions 5.5.6 and 5.6.1 to avoid the overlap which they traditionally had (and still have in MySQL 5.0 and 5.1). However, the RPM meta information had not been changed in accordance, and so RPM still assumed a conflict between shared and shared-compat RPM packages. This has been fixed. 
- myisam_sort_buffer_size could not be set larger than 4GB on 64-bit systems. 
- Due to improper locking, concurrent inserts into an ARCHIVE table at the same time as repair and check operations on the table resulted in table corruption.

更新時間：2012-02-21
更新細節：

What's new in this version:

Functionality Added or Changed:
- A new CMake option, MYSQL_PROJECT_NAME, can be set on Windows or Mac OS X to be used in the project name. 

Bugs Fixed:
- Performance: InnoDB Storage Engine: Memory allocation for InnoDB tables 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 TABLES statements. 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. 
- Incompatible Change: An earlier change (in MySQL 5.1.62 and 5.5.21) 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: CONVERT_TZ(), DATE_ADD(), DATE_SUB(), DAYOFYEAR(), LAST_DAY(), TIMESTAMPDIFF(), TO_DAYS(), TO_SECONDS(), WEEK(), WEEKDAY(), WEEKOFYEAR(), YEARWEEK(). The previous behavior has been restored. 
- InnoDB Storage Engine: A Valgrind error was fixed in the function os_aio_init(). 
- InnoDB Storage Engine: The server could crash when creating an InnoDB temporary table under Linux, if the $TMPDIR setting points to a tmpfs filesystem and innodb_use_native_aio is 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_aio setting or use a different temporary directory. The fix causes InnoDB to turn off the innodb_use_native_aio setting automatically if it detects that the temporary file directory does not support asynchronous I/O. 
- InnoDB Storage Engine: References to C preprocessor symbols and macros HAVE_purify, UNIV_INIT_MEM_TO_ZERO, and UNIV_SET_MEM_TO_ZERO were removed from the InnoDB source code. They were only used in debug builds instrumented for Valgrind. They are replaced by calls to the UNIV_MEM_INVALID() macro. 
- InnoDB Storage Engine: 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 InnoDB change buffer. The workaround was to set the configuration option innodb_change_buffering=inserts. 
- InnoDB Storage Engine: With 1024 concurrent InnoDB transactions running concurrently and the innodb_file_per_table setting enabled, a CREATE TABLE operation for an InnoDB table could fail. The .ibd file from the failed CREATE TABLE was left behind, preventing the table from being created later, after the load had dropped. The fix adds error handling to delete the erroneous .ibd file. This error was less likely to occur in MySQL 5.5 and 5.6, because raising the number of InnoDB undo slots increased the number of simultaneous transactions needed to trigger the bug, from 1K to 128K. 
- Replication: Executing mysqlbinlog with the --start-position=N option, where N was 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. 
- Replication: On Windows replication slave hosts, STOP SLAVE took an excessive length of time to complete when the master was down. 
- A query that used an index on a CHAR column referenced in a BETWEEN clause could return invalid results. 
- Expressions that compared a BIGINT column 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 <, >, <=, >=, =, !=/<>, IN, or BETWEEN yielding false positive or negative results. 
- When the optimizer performed conversion of DECIMAL values while evaluating range conditions, it could produce incorrect results. 
- When running mysqldump with both the --single-transaction and --flush-logs options, the flushing of the log performed an implicit COMMIT (see Section 12.3.3, “Statements That Cause an Implicit Commit”), causing more than one transaction to be used and thus breaking consistency. 
- 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. 
- When used with the --xml option, mysqldump --routines failed to dump any stored routines, triggers, or events. 
- It was possible on replication slaves where FEDERATED tables were in use to get timeouts on long-running operations, such as Error 1160 Got an error writing communication packets. The FEDERATED tables did not need to be replicated for the issue to occur. 
- 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. 
- 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. 
- On Windows, the server incorrectly constructed the full path name of the plugin binary for INSTALL PLUGIN and CREATE FUNCTION ... SONAME. 
- 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.

更新時間：2012-02-21
更新細節：

What's new in this version:

Functionality Added or Changed:
- A new CMake option, MYSQL_PROJECT_NAME, can be set on Windows or Mac OS X to be used in the project name. 

Bugs Fixed:
- Performance: InnoDB Storage Engine: Memory allocation for InnoDB tables 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 TABLES statements. 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. 
- Incompatible Change: An earlier change (in MySQL 5.1.62 and 5.5.21) 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: CONVERT_TZ(), DATE_ADD(), DATE_SUB(), DAYOFYEAR(), LAST_DAY(), TIMESTAMPDIFF(), TO_DAYS(), TO_SECONDS(), WEEK(), WEEKDAY(), WEEKOFYEAR(), YEARWEEK(). The previous behavior has been restored. 
- InnoDB Storage Engine: A Valgrind error was fixed in the function os_aio_init(). 
- InnoDB Storage Engine: The server could crash when creating an InnoDB temporary table under Linux, if the $TMPDIR setting points to a tmpfs filesystem and innodb_use_native_aio is 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_aio setting or use a different temporary directory. The fix causes InnoDB to turn off the innodb_use_native_aio setting automatically if it detects that the temporary file directory does not support asynchronous I/O. 
- InnoDB Storage Engine: References to C preprocessor symbols and macros HAVE_purify, UNIV_INIT_MEM_TO_ZERO, and UNIV_SET_MEM_TO_ZERO were removed from the InnoDB source code. They were only used in debug builds instrumented for Valgrind. They are replaced by calls to the UNIV_MEM_INVALID() macro. 
- InnoDB Storage Engine: 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 InnoDB change buffer. The workaround was to set the configuration option innodb_change_buffering=inserts. 
- InnoDB Storage Engine: With 1024 concurrent InnoDB transactions running concurrently and the innodb_file_per_table setting enabled, a CREATE TABLE operation for an InnoDB table could fail. The .ibd file from the failed CREATE TABLE was left behind, preventing the table from being created later, after the load had dropped. The fix adds error handling to delete the erroneous .ibd file. This error was less likely to occur in MySQL 5.5 and 5.6, because raising the number of InnoDB undo slots increased the number of simultaneous transactions needed to trigger the bug, from 1K to 128K. 
- Replication: Executing mysqlbinlog with the --start-position=N option, where N was 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. 
- Replication: On Windows replication slave hosts, STOP SLAVE took an excessive length of time to complete when the master was down. 
- A query that used an index on a CHAR column referenced in a BETWEEN clause could return invalid results. 
- Expressions that compared a BIGINT column 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 <, >, <=, >=, =, !=/<>, IN, or BETWEEN yielding false positive or negative results. 
- When the optimizer performed conversion of DECIMAL values while evaluating range conditions, it could produce incorrect results. 
- When running mysqldump with both the --single-transaction and --flush-logs options, the flushing of the log performed an implicit COMMIT (see Section 12.3.3, “Statements That Cause an Implicit Commit”), causing more than one transaction to be used and thus breaking consistency. 
- 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. 
- When used with the --xml option, mysqldump --routines failed to dump any stored routines, triggers, or events. 
- It was possible on replication slaves where FEDERATED tables were in use to get timeouts on long-running operations, such as Error 1160 Got an error writing communication packets. The FEDERATED tables did not need to be replicated for the issue to occur. 
- 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. 
- 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. 
- On Windows, the server incorrectly constructed the full path name of the plugin binary for INSTALL PLUGIN and CREATE FUNCTION ... SONAME. 
- 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.

更新時間：2012-01-13
更新細節：

What's new in this version:

Bugs Fixed:
- InnoDB Storage Engine: Issuing INSERT...ON DUPLICATE KEY statements for InnoDB tables from concurrent threads could cause a deadlock, particularly with the INSERT...ON DUPLICATE KEY UPDATE form. The fix avoids deadlocks caused by the same row being accessed by more than one transaction. Deadlocks could still occur when multiple rows are inserted and updated simultaneously by different transactions in inconsistent order; those types of deadlocks require the standard error handling on the application side, of re-trying the transaction. 
- An incorrect InnoDB assertion could cause the server to halt. This issue only affected debug builds. The assertion referenced the source file btr0pcur.ic and the variable cursor->pos_state. 
- The handle_segfault() signal-handler code in mysqld could itself crash due to calling unsafe functions. 
- ARCHIVE tables with NULL columns could cause server crashes or become corrupt under concurrent load. 
- Enabling myisam_use_mmap could cause the server to crash. 
- Concurrent access to ARCHIVE tables could cause corruption.

更新時間：2012-01-13
更新細節：

What's new in this version:

Bugs Fixed:
- Important Change: Replication: Setting an empty user in a CHANGE MASTER TO statement caused an invalid internal result and is no longer permitted. Trying to use MASTER_USER='' or setting MASTER_PASSWORD while leaving MASTER_USER unset causes the statement to fail with an error.
- Important Change: Replication: Moving the binary log file, relay log file, or both files to a new location, then restarting the server with a new value for --log-bin, --relay-log, or both, caused the server to abort on start. This was because the entries in the index file overrode the new location. In addition, paths were calculated relative to datadir (rather than to the --log-bin or --relay-log values). The fix for this problem means that, when the server reads an entry from the index file, it now checks whether the entry contains a relative path. If it does, the relative part of the path is replaced with the absolute path set using the --log-bin or --relay-log option. An absolute path remains unchanged; in such a case, the index must be edited manually to enable the new path or paths to be used.
- InnoDB Storage Engine: When doing a live downgrade from MySQL 5.6.4 or later, with innodb_page_size set to a value other than 16384, now the earlier MySQL version reports that the page size is incompatible with the older version, rather than crashing or displaying a “corruption” error.
- InnoDB Storage Engine: Issuing INSERT...ON DUPLICATE KEY statements for InnoDB tables from concurrent threads could cause a deadlock, particularly with the INSERT...ON DUPLICATE KEY UPDATE form. The fix avoids deadlocks caused by the same row being accessed by more than one transaction. Deadlocks could still occur when multiple rows are inserted and updated simultaneously by different transactions in inconsistent order; those types of deadlocks require the standard error handling on the application side, of re-trying the transaction.
- An incorrect InnoDB assertion could cause the server to halt. This issue only affected debug builds. The assertion referenced the source file btr0pcur.ic and the variable cursor->pos_state.
- Locale information for FORMAT() function instances was lost in view definitions.
- The handle_segfault() signal-handler code in mysqld could itself crash due to calling unsafe functions.
- Enabling myisam_use_mmap could cause the server to crash.
- Concurrent access to ARCHIVE tables could cause corruption.

更新時間：2012-01-13
更新細節：

What's new in this version:

Bugs Fixed:
- Important Change: Replication: Setting an empty user in a CHANGE MASTER TO statement caused an invalid internal result and is no longer permitted. Trying to use MASTER_USER='' or setting MASTER_PASSWORD while leaving MASTER_USER unset causes the statement to fail with an error. 
- Important Change: Replication: Moving the binary log file, relay log file, or both files to a new location, then restarting the server with a new value for --log-bin, --relay-log, or both, caused the server to abort on start. This was because the entries in the index file overrode the new location. In addition, paths were calculated relative to datadir (rather than to the --log-bin or --relay-log values). The fix for this problem means that, when the server reads an entry from the index file, it now checks whether the entry contains a relative path. If it does, the relative part of the path is replaced with the absolute path set using the --log-bin or --relay-log option. An absolute path remains unchanged; in such a case, the index must be edited manually to enable the new path or paths to be used. 
- InnoDB Storage Engine: When doing a live downgrade from MySQL 5.6.4 or later, with innodb_page_size set to a value other than 16384, now the earlier MySQL version reports that the page size is incompatible with the older version, rather than crashing or displaying a “corruption” error. 
- InnoDB Storage Engine: Issuing INSERT...ON DUPLICATE KEY statements for InnoDB tables from concurrent threads could cause a deadlock, particularly with the INSERT...ON DUPLICATE KEY UPDATE form. The fix avoids deadlocks caused by the same row being accessed by more than one transaction. Deadlocks could still occur when multiple rows are inserted and updated simultaneously by different transactions in inconsistent order; those types of deadlocks require the standard error handling on the application side, of re-trying the transaction. 
- An incorrect InnoDB assertion could cause the server to halt. This issue only affected debug builds. The assertion referenced the source file btr0pcur.ic and the variable cursor->pos_state. 
- Locale information for FORMAT() function instances was lost in view definitions. 
- The handle_segfault() signal-handler code in mysqld could itself crash due to calling unsafe functions. 
- Enabling myisam_use_mmap could cause the server to crash. 
- Concurrent access to ARCHIVE tables could cause corruption.

更新時間：2011-12-09
更新細節：

What's new in this version:

Bugs Fixed
- InnoDB Storage Engine: An incorrect deadlock could occur on a server doing a substantial amount of change buffering for DML operations, particularly DELETE statements.
- Rounding DBL_MAX returned DBL_MAX, not 'inf'. 
- mysql_upgrade did not upgrade the system tables or create the mysql_upgrade_info file when run with the --write-binlog or --skip-write-binlog option. 
- If a plugin was uninstalled, thread local variables for plugin variables of string type with wth PLUGIN_VAR_MEMALLOC flag were not freed. 
- Deadlock could occur when these four things happened at the same time: 1) An old dump thread was waiting for the binary log to grow. 2) The slave server that replicates from the old dump thread tried to reconnect. During reconnection, the new dump thread tried to kill the old dump thread. 3) A KILL statement tried to kill the old dump thread. 4) An INSERT statement caused a binary log rotation.

更新時間：2011-12-09
更新細節：

What's new in this version:

Bugs Fixed
- InnoDB Storage Engine: An incorrect deadlock could occur on a server doing a substantial amount of change buffering for DML operations, particularly DELETE statements.
- Rounding DBL_MAX returned DBL_MAX, not 'inf'. 
- mysql_upgrade did not upgrade the system tables or create the mysql_upgrade_info file when run with the --write-binlog or --skip-write-binlog option. 
- If a plugin was uninstalled, thread local variables for plugin variables of string type with wth PLUGIN_VAR_MEMALLOC flag were not freed. 
- Deadlock could occur when these four things happened at the same time: 1) An old dump thread was waiting for the binary log to grow. 2) The slave server that replicates from the old dump thread tried to reconnect. During reconnection, the new dump thread tried to kill the old dump thread. 3) A KILL statement tried to kill the old dump thread. 4) An INSERT statement caused a binary log rotation.