Functionality Added or Changed
comp_err now checks to make sure that new errors are not being added to MySQL 5.1 or 5.5 because the set of errors for these series is frozen. (Bug #16807394)
During an insert buffer merge, InnoDB would invoke
lock_rec_restore_from_page_infimum() on a
potentially invalid record pointer.
page_zip_validate() consistency check
would fail after compressing a page, in
page_zip_compress(). This problem was caused
page_zip_decompress(), which would fail to
heap_no correctly when a record contained
no user data bytes. A record with no user data bytes occurs
when, for example, a primary key is an empty string and all
secondary index fields are NULL or an empty string.
commit_threads_m, which was initialized but
never used, has been removed from the code base.
(Bug #60225, Bug #11829813)
When dropping a partitioned table, the table's
.par file was deleted first, before the
table definition or data. This meant that, if the server failed
during the drop operation, the table could be left in an
inconsistent state in which it could neither be accessed nor
The fix for this problem makes the following changes:
Now, when dropping a partitioned table, the table's
.par file is not removed until all
table data has been deleted.
DROP TABLE of
a partitioned table, in the event that its
.par file is determined to be missing,
.frm file is now
immediately deleted, in effect forcing the drop to complete.
(Bug #13548704, Bug #63884)
Shared-compatibility conflict errors occurred for RPM install operations, even if no shared-compatibility RPMs were already installed. (Bug #16678122)
A user variable referenced during execution of a prepared statement is set to memory that is freed at the end of execution. A second execution of the statement could result in Valgrind warnings when accessing this memory. (Bug #16119355)
Misoptimization of left expressions in prepared statements could cause a server exit. (Bug #16095534)
Prepared statement needs to be
re-prepared errors, inserts into
DECIMAL columns caused a server
Assigning the result of a subquery to a user variable raised an
assertion when the outer query included
(Bug #57196, Bug #11764371)