Beginning with MySQL 5.5.29, Oracle no longer provides binaries for Mac OS X 10.5, Debian 5, RHEL/OL 4, FreeBSD 7, Windows XP, or Windows 2003.
The timing values for low-level
operations were adjusted for better performance with fast
storage devices, such as SSD.
This enhancement primarily affects read operations for
BLOB columns in
(Bug #13702112, Bug #64258)
did not work for
expr values greater
than the largest signed
value. Such arguments now are accepted, with some consequences
for compatibility with previous versions:
(Bug #20964, Bug #11745891)
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 fix
reduces the excessive
locking by releasing the
locks of unmatched rows. This optimization affects only
transactions with isolation level equal to or less strict than
READ COMMITTED; it does not
apply to transactions using
SERIALIZABLE isolation level.
An online DDL operation for an
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.
CREATE TABLE statement
failed due to a disk full error, some memory allocated during
the operation was not freed properly.
This fix makes MySQL more responsive to
statements when the query is accessing an
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. After a restart, MySQL could crash after reading the corresponding secondary index page. 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. (Bug #14636528, Bug #66819, Bug #58571, Bug #61104, Bug #65443)
setting enabled, a
operation could cause a crash, due to a race condition that
depended on the timing of pending I/O requests.
(Bug #14594600, Bug #66718)
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. (Bug #14500557, Bug #14537695)
When an auto-increment column used a
DOUBLE data type, if the auto-increment value
became very large (larger than the maximum
long long value), subsequent inserts could fail or
cause the server to halt.
(Bug #14145950, Bug #55071)
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:
ER_TABLE_DEF_CHANGED: insufficient history for index
This issue could cause an assertion error in debug builds. (Bug #14036214)
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. 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 Code 1118: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. You have to change some columns to TEXT or BLOBs
A workaround for the problem was to create the table with the
ROW_FORMAT=COMPRESSED clause, which is now
suggested in the message.
(Bug #13453036, Bug #63507)
In rare circumstances, MySQL could apply
records out of order during a
ROLLBACK of an operation
that modified a BLOB column. This issue could cause an assertion
error in debug builds:
In debug builds, a mismatch in the
PAGE_FREE list would cause an assertion.
Updates writing user variables whose values were never set on a
slave while using
cause the slave to fail.
References: This bug was introduced by Bug #14275000.
Replication: Following an insert into a nontransactional table that failed due to insufficient disk space, the server did not properly clean up all pending events, leading to an assert or possibly to other errors. (Bug #11750014)
`) characters were not always
handled correctly in internally generated SQL statements, which
could sometimes lead to errors on replication slaves or cause
failure of restore operations from binary log files.
(Bug #66550, Bug #14548159, Bug #29422, Bug #11746883)
Within a stored procedure, executing a multiple-table
DELETE statement that used a very
long table alias could cause the server to exit.
Very long table aliases in queries could cause the server to exit. (Bug #15948123)
Very long database names in queries could cause the server to exit. (Bug #15912213, Bug #16900358)
Attempting to create an
InnoDB table with a
NULL type attribute could cause a serious
DELETE statement for an
InnoDB table could write incorrect
transaction metadata into a record, causing the server to halt
with an error. To work around this issue, reduce the specified
length of the primary key to less than 1K bytes.
Repeated execution of a query containing a subquery that used
MAX() could result in increasing
could fail with
Unknown database when
dbname contained multiple backtick
Within a stored program, memory allocated to hold condition information was not released until program exit, leading to excessive memory use. (Bug #14640599)
SHOW PROFILE could be used to
cause excessive server memory consumption.
The thread cache implementation worked in LIFO rather than FIFO fashion and could result in a thread being denied service (although this was a remote possibility). (Bug #14621627)
The configure.pl script that converts GNU
configure options to CMake
equivalents generated erroneous output for the
--with-mysqld-ldflags options. It now ignores
Improper memory cleanup could cause the server to exit. (Bug #14536113)
INFORMATION_SCHEMA tables through a
view could leak memory.
A memory leak could occur for queries containing a subquery that
GROUP BY on an outer column.
On Microsoft Windows with CMake 2.6, the build process would not
stop if the
create_initial_db step failed.
The test in mysqld_safe for the presence of
--plugin_dir option and
assignment of a default value to it were performed before the
actual argument parsing took place.
Improper memory cleanup could cause the server to exit. (Bug #13340270)
A memory leak occurred due to failure to clean up after
(Bug #12694872, Bug #14542543)
myisamchk now has a
myisam_sort_buffer_size variable available as
an alternative name to
myisam_sort_buffer_size is preferable to
sort_buffer_size because its name corresponds
server system variable that has a similar meaning.
sort_buffer_size should be considered
(Bug #11754894, Bug #46578)
The number of connection errors from a given host as counted by
the server was periodically reset, with the result that
max_connect_errors was never
reached and invalid hosts were never blocked from trying to
References: See also Bug #38247, Bug #43006, Bug #45584, Bug #45606.
RHEL RPM packages had a conflict between
(Bug #67965, Bug #16041010)
In debug builds, an
assertion was overly aggressive about prohibiting an open range.
(Bug #66513, Bug #14547952)
On Windows, the Perl version of mysql_install_db created system tables in the mysql database that were not populated properly. (Bug #65584, Bug #14181049)
mysqld_safe ignored the value of the
UMASK environment variable, leading to
behavior different from mysqld with respect
to the access mode of created files. Now
mysqld_multi) attempt to approximate the same
behavior as mysqld.
(Bug #57406, Bug #11764559)
ZEROFILL values may be
converted to string constants. However,
CASE expressions did not handle
switching data types after the planning stage, leading to
CASE finding a null pointer instead
of its argument.
(Bug #57135, Bug #11764313)