Security Fix: A security bug was fixed. (Bug #57477)
Security Fix: A security bug was fixed. (Bug #57272)
Security Fix: A security bug was fixed. (Bug #56814)
Security Fix: A security bug was fixed. (Bug #55146, Bug #56287)
Security Fix: A security bug was fixed. (Bug #54484)
InnoDB: A followup fix to bug #54678.
TRUNCATE TABLEcould still cause a crash (assertion error) in the debug version of the server. (Bug #57700)
InnoDBsystem tablespace could grow continually for a server under heavy load. (Bug #57611)
InnoDB: If the server crashed during an
ALTER TABLEoperation on an
InnoDBtable, examining the table through
SHOW CREATE TABLEor querying the
INFORMATION_SCHEMAtables could cause the server to stop with an assertion error. (Bug #56982)
InnoDB: A query for an
InnoDBtable 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)
InnoDB: A large number of foreign key declarations could cause the output of the
SHOW CREATE STATEMENTstatement to be truncated. (Bug #56143)
InnoDB: A compilation problem affected the
InnoDBsource code on NetBSD/sparc64. (Bug #53916)
References: See also Bug #59327.
SET PASSWORDcaused failure of row-based replication between a MySQL 5.1 master and a MySQL 5.5 slave.
This fix makes it possible to replicate
SET PASSWORDcorrectly, 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 release. (Bug #57098)
References: See also Bug #55452, Bug #57357.
ALTER TABLEstatement that altered a column of a
MyISAMtable 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 SLAVEis 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
CREATE TEMPORARY TABLEstatements,
DROP TEMPORARY TABLEstatements, 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 SLAVEstatement, 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 case).
Following this fix, if an ongoing transaction contains
CREATE TEMPORARY TABLEstatements,
DROP TEMPORARY TABLEstatements, or both, the SQL thread now waits until the transaction ends, then stops. (Bug #56118, Bug #11763416)
Replication: 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
CREATE TABLE ... SELECTstatement that creates a nontemporary table having the same name as an existing temporary table. When such a statement was replicated using the
MIXEDlogging format, and the statement was unsafe for row-based logging, updates were misapplied to the temporary table. (Bug #55478)
References: See also Bug #47899, Bug #55709.
Replication: When a slave tried to execute a transaction larger than the slave's value for
max_binlog_cache_size, it crashed. This was caused by an assertion that the server should roll back only the statement but not the entire transaction when the error
ER_TRANS_CACHE_FULLoccurred. However, the slave SQL thread always rolled back the entire transaction whenever any error occurred, regardless of the type of error. (Bug #55375)
Replication: 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. (Bug #55263)
Replication: Trying to read from a binary log containing a log event of an invalid type caused the slave to crash. (Bug #38718)
Replication: When replicating the
Grantorcolumn was not replicated, and was thus left empty on the slave. (Bug #27606)
SET GLOBAL debugcould cause a crash on Solaris if the server failed to open the trace file. (Bug #57274)
References: This bug is a regression of Bug #38999.
On file systems with case insensitive file names, and
lower_case_table_names=2, the server could crash due to a table definition cache inconsistency. (Bug #46941)
Handling of host name lettercase in
GRANTstatements was inconsistent. (Bug #36742)