Security Fix: A security bug was fixed. (Bug #55146, Bug #56287)
Security Fix: A security bug was fixed. (Bug #56814)
Security Fix: A security bug was fixed. (Bug #54484)
Security Fix: A security bug was fixed. (Bug #57272)
Security Fix: A security bug was fixed. (Bug #57477)
InnoDB system tablespace could grow
continually for a server under heavy load.
A followup fix to bug #54678.
TABLE could still cause a crash (assertion error) in
the debug version of the server.
A large number of foreign key declarations could cause the
output of the
SHOW CREATE STATEMENT statement
to be truncated.
If the server crashed during an
TABLE operation on an
examining the table through
SHOW CREATE TABLE
or querying the
could cause the server to stop with an assertion error.
A compilation problem affected the
source code on NetBSD/sparc64.
References: See also Bug #59327.
A query for an
InnoDB table could
return the wrong value if a column value was changed to a
different case, and the column had a case-insensitive index.
(Bug #56680, Bug #11763909)
If there exist both a temporary table and a nontemporary table
having the same name, updates normally apply only to the
temporary table, with the exception of a
TABLE ... SELECT statement that creates a nontemporary
table having the same name as an existing temporary table. When
such a statement was replicated using the
MIXED logging format, and the statement was
unsafe for row-based logging, updates were misapplied to the
References: See also Bug #47899, Bug #55709.
ALTER TABLE statement that
altered a column of a
without setting the column's size caused the binary log to
become corrupted when the table map was unexpectedly set to 0 by
updates (including deletes) on multiple tables, leading to
replication failure when more than one table received the same
table map ID.
(Bug #56226, Bug #11763509)
STOP SLAVE is issued, the
slave SQL thread rolls back the current transaction and stops
immediately if the transaction updates only tables which use
transactional storage engines. Previously, this occurred even
when the transaction contained
TABLE statements, or both, although these statements
cannot be rolled back. Because temporary tables persist for the
lifetime of a user session (in the case, the replication user),
they remain until the slave is stopped or reset. When the
transaction is restarted following a subsequent
START SLAVE statement, the SQL
thread aborts with an error that a temporary table to be created
(or dropped) already exists (or does not exist, in the latter
Following this fix, if an ongoing transaction contains
TABLE statements, or both, the SQL thread now waits
until the transaction ends, then stops.
(Bug #56118, Bug #11763416)
When making changes to relay log settings using
CHANGE MASTER TO, the I/O cache
was not cleared. This could result in replication failure when
the slave attempted to read stale data from the cache and then
stopped with an assertion.
Replication: Trying to read from a binary log containing a log event of an invalid type caused the slave to crash. (Bug #38718)
SET PASSWORD caused failure of
row-based replication between a MySQL 5.1 master and a MySQL 5.5
This fix makes it possible to replicate
PASSWORD correctly, using row-based replication
between a master running MySQL 5.1.53 or a later MySQL 5.1
release to a slave running MySQL 5.5.7 or a later MySQL 5.5
References: See also Bug #55452, Bug #57357.
When a slave tried to execute a transaction larger than the
slave's value for
crashed. This was caused by an assertion that the server should
roll back only the statement but not the entire transaction when
occurred. However, the slave SQL thread always rolled back the
entire transaction whenever any error occurred, regardless of
the type of error.
When replicating the
Grantor column was not replicated, and
was thus left empty on the slave.
Handling of host name lettercase in
GRANT statements was
On file systems with case insensitive file names, and
server could crash due to a table definition cache
debug could cause a crash on Solaris if the server
failed to open the trace file.
References: This bug is a regression of Bug #38999.