Functionality Added or Changed
A deprecation warning is now issued when
--ignore-builtin-innodb is used.
yaSSL was upgraded from version 1.7.2 to 2.2.0. (Bug #13706828)
References: See also Bug #13713205.
Security Fix: A security bug was fixed. (Bug #63775)
Important Change; InnoDB:
When a row grew in size due to an
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
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
ROW_FORMAT=COMPRESSED along with the
Barracuda file format, particularly with the
enabled, because page allocation operations are more common as
.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. (Bug #13721257, Bug #12612184, Bug #12704861)
An erroneous assertion could occur, in debug builds only, when
creating an index on a column containing zero-length values
A DDL operation such as
ALTER TABLE ... ADD
COLUMN could stall, eventually timing out with an
Error 1005: Can't create table message
(Bug #13636122, Bug #62100, Bug #63553)
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.
(Bug #12739098, Bug #62401)
Server startup could produce an error for temporary tables using
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,
set to its normal value without a trailing slash, for example
/var/tmp. On startup, MySQL would see the
.frm file and issue
TABLE for the orphaned temporary table.
(Bug #11754376, Bug #45976)
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
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
(Bug #11758263, Bug #50440)
After using an
statement to change the
property for an
InnoDB table, for example
when switching from an uncompressed to a compressed table,
subsequent server restarts could fail with a message like:
InnoDB: Error: data file
path/ibdata2 uses page size 1024, InnoDB: but the only supported page size in this release is=16384
This issue is a regression introduced in MySQL 5.5.20. (Bug #13698765, Bug #64160)
The contents of the
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
RPM packages. This has been fixed.
(Bug #60855, Bug #12368215)
References: See also Bug #56150.
not be set larger than 4GB on 64-bit systems.
(Bug #45702, Bug #11754145)
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
(Bug #37280, Bug #11748748)