![]() * Replication: Backtick (`) characters were not always handled correctly in internally generated SQL statements, which could sometimes lead to errors on the slave. * Replication: Updates writing user variables whose values were never set on a slave while using -replicate-ignore-table could cause the slave to fail. This issue could cause an assertion error in debug builds: * InnoDB: In rare circumstances, MySQL could apply InnoDB undo records out of order during a ROLLBACK of an operation that modified a BLOB column. A workaround for the problem was to create the table with the ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED clause, which is now suggested in the message. You have to change some columns to TEXT or BLOBs The maximum row size for the used table type, not counting BLOBs, is 8126. The old message, was misleading it suggested using BLOBs, when the 768-byte prefix for each BLOB column was the cause of the limit error: #Download mysql server 5.5 for windows update* InnoDB: The error message was improved for the case where an UPDATE failed because the row included several BLOB values greater than 768 bytes each, causing the size of a row to exceed half the page size. This issue could cause an assertion error in debug builds. HA_ERR_TABLE_DEF_CHANGED: insufficient history for index ![]() * InnoDB: If a transaction was started with a consistent snapshot, then new indexes were added to the table while the transaction was in progress, a subsequent UPDATE statement could incorrectly encounter the error: * InnoDB: When an auto-increment column used a FLOAT or DOUBLE data type, if the auto-increment value became very large (larger than the maximum unsigned long long value), subsequent inserts could fail or cause the server to halt. * InnoDB: If a table was defined with an index key length very close to the upper length limit of 3072, a query against that table could cause a serious error. * InnoDB: Inserting data of varying record lengths into an InnoDB table that used compression could cause the server to halt with an error. The problem was more likely to occur in MySQL 5.5 or later, where the original insert buffering mechanism was generalized to cover other operations. After a restart, MySQL could crash after reading the corresponding secondary index page. * InnoDB: If the server crashed at the specific point when a change buffer entry was being merged into a buffer pool page, the transaction log and the change buffer were left in an inconsistent state. * InnoDB: With the innodb_file_per_table setting enabled, a DROP TABLE operation could cause a crash, due to a race condition that depended on the timing of pending I/O requests. #Download mysql server 5.5 for windows full* InnoDB: If a CREATE TABLE statement failed due to a disk full error, some memory allocated during the operation was not freed properly. * InnoDB: An online DDL operation for an InnoDB table incorrectly reported an empty value ('') instead of the correct key value when it reported a duplicate key error for a unique index using an index prefix. This optimization affects only transactions with isolation level equal to or less strict than READ COMMITTED it does not apply to transactions using REPEATABLE READ or SERIALIZABLE isolation level. ![]() This fix reduces the excessive locking by releasing the locks of unmatched rows. ![]() * Important Change: InnoDB: A DML statement using the index merge access method could lock many rows from the table, even when those rows were not part of the final result set. This enhancement primarily affects read operations for BLOB columns in compressed tables. * Performance: InnoDB: The timing values for low-level InnoDB read operations were adjusted for better performance with fast storage devices, such as SSD. * The SHOW AUTHORS and SHOW CONTRIBUTORS statements are now deprecated in MySQL 5.5 and have been removed in MySQL 5.6. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |