Boolean system variables can be enabled at run time by setting
them to the value ON or
OFF, but previously this did not work at
server startup. Now at startup such variables can be enabled by
setting them to ON or
TRUE. Any other nonnumeric value is
interpreted as OFF. (Bug #46393 improves on
this such that ON, TRUE,
OFF, and FALSE are
recognized, and other values are invalid.)
(Bug #51631, Bug #11759326)

References: See also: Bug #46393, Bug #11754743.

In the audit plugin interface, the
MYSQL_AUDIT_CONNECTION_CLASS event class was
added, and the MYSQL_AUDIT_GENERAL_STATUS
subclass was added to the
MYSQL_AUDIT_GENERAL_CLASS event class. The
new symbol definitions can be found in the
plugin_audit.h header file.

Bugs Fixed

Security Fix:
A security bug was fixed.
(Bug #57952)

Performance; InnoDB:
An UPDATE statement for an
InnoDB table could be slower than
necessary if it changed a column covered by a prefix index, but
did not change the prefix portion of the value. The fix improves
performance for InnoDB 1.1 in MySQL 5.5 and higher, and the
InnoDB Plugin for MySQL 5.1.
(Bug #58912, Bug #11765900)

Performance; InnoDB:
Synchronization inside InnoDB frequently involves the use of
spin loops: while
waiting, InnoDB executes a tight loop of instructions repeatedly
to avoid having the InnoDB
process and
threads be rescheduled by the
operating system. If the spin loops are executed too quickly,
system resources are wasted, imposing a performance penalty on
transaction throughput. Most modern processors implement the
PAUSE instruction for use in spin loops, so
the processor can be more efficient.

InnoDB now uses the PAUSE instruction in its
spin loops on all platforms where such an instruction is
available. Previously, InnoDB used
the PAUSE instruction only on Windows
systems. Use of the PAUSE instruction
increases overall performance with CPU-bound workloads, and
provides the added benefit of minimizing power consumption
during the execution of the spin loops.
(Bug #58666)

Performance:
Queries involving InnoDB tables in
the INFORMATION_SCHEMA tables
TABLE_CONSTRAINTS,
KEY_COLUMN_USAGE, or
REFERENTIAL_CONSTRAINTS were slower
than necessary because statistics were rechecked more often than
required, even more so when many foreign keys were present. The
improvement to this may be of particular benefit to users of
MySQL Enterprise Monitor with many monitored servers or tens of
thousands of tables.
(Bug #43818, Bug #11752585)

Incompatible Change:
When auto_increment_increment is greater than
one, values generated by a bulk insert that reaches the maximum
column value could wrap around rather producing an overflow
error.

As a consequence of the fix, it is no longer possible for an
auto-generated value to be equal to the maximum BIGINT
UNSIGNED value. It is still possible to store that
value manually, if the column can accept it.
(Bug #39828, Bug #11749800)

Important Change; Partitioning:
Date and time functions used as partitioning functions now have
the types of their operands checked; use of a value of the wrong
type is now disallowed in such cases. In addition,
EXTRACT(WEEK FROM
col_name), where
col_name is a
DATE or
DATETIME column, is now
disallowed altogether because its return value depends on the
value of the
default_week_format system
variable.
(Bug #54483, Bug #11761948)

References: See also: Bug #57071, Bug #11764255.

InnoDB; Partitioning:
The partitioning handler did not pass locking information to a
table's storage engine handler. This caused high contention
and thus slower performance when working with partitioned
InnoDB tables.
(Bug #59013)

InnoDB:
The presence of a double quotation mark inside the
COMMENT field for a column could prevent a
foreign key constraint from being created properly.
(Bug #59197, Bug #11766154)

InnoDB:
When multiple InnoDB buffer pools
were enabled, SHOW
ENGINE INNODB statements displayed information about
each one, but not summary information combining statistics for
the entire buffer pool subsystem. Now, the aggregated
information is displayed in the BUFFER POOL AND
MEMORY section, and information about individual
buffer pool instances is displayed in a new INDIVIDUAL
BUFFER POOL INFO section.
(Bug #58461)

InnoDB:
The command to create a debug build (cmake -DWITH_DEBUG
...) now automatically sets the
InnoDB debugging flag
UNIV_DEBUG on all platforms. Formerly, the
UNIV_DEBUG flag might not be set for Windows
platforms with Visual Studio and not on OS X with Xcode.
(Bug #58279)

InnoDB:
In InnoDB status output, the value
for I/O sum[] could be incorrect, displayed
as a very large number.
(Bug #57600)

InnoDB:
The server could crash with an assertion error, if a stored
procedure, stored function, or trigger modified one
InnoDB table containing an
auto-increment
column, and dropped another InnoDB
table containing an auto-increment column.
(Bug #56228)

InnoDB:
It was not possible to query the
information_schema.INNODB_TRX table
while other connections were running queries involving
BLOB types.
(Bug #55397, Bug #11762763)

InnoDB:
When the lower_case_table_names
variable was set to 2, InnoDB could
fail to restore a mysqldump dump of a table
with foreign key constraints involving case-sensitive names.
(Bug #55222)

InnoDB:
The OPTIMIZE TABLE statement
reset the auto-increment counter for an
InnoDB table. Now the
auto-increment value is preserved across this operation.
(Bug #18274)

Replication:
While an INSERT DELAYED statement
with a single inserted value does not return any visible
warnings, such a warning could be still written into the error
log.
(Bug #57666, Bug #11764793)

References: See also: Bug #49567.

Replication:
When closing a session that used temporary tables, binary
logging could sometimes fail with a spurious Failed
to write the DROP statement for temporary tables to binary
log.
(Bug #57288)

Replication:
Due to changes made in MySQL 5.5.3, settings made in the
binlog_cache_size and
max_binlog_cache_size server
system variables affected both the binary log statement cache
(also introduced in that version) and the binary log
transactional cache (formerly known simply as the binary log
cache). This meant that the resources used as a result of
setting either or both of these variables were double the amount
expected. To rectify this problem, these variables now affect
only the transactional cache. The fix for this issue also
introduces two new system variables
binlog_stmt_cache_size and
max_binlog_stmt_cache_size,
which affect only the binary log statement cache.

In addition, the
Binlog_cache_use status
variable was incremented whenever either cache was used, and
Binlog_cache_disk_use was
incremented whenever the disk space from either cache was used,
which caused problems with performance tuning of the statement
and transactional caches, because it was not possible to
determine which of these was being exceeded when attempting to
troubleshoot excessive disk seeks and related problems. This
issue is solved by changing the behavior of these two status
variables such that they are incremented only in response to
usage of the binary log transactional cache, as well as by
introducing two new status variables
Binlog_stmt_cache_use and
Binlog_stmt_cache_disk_use,
which are incremented only by usage of the binary log statement
cache.

Replication:
By default, a value is generated for an
AUTO_INCREMENT column by inserting either
NULL or 0 into the column. Setting the
NO_AUTO_VALUE_ON_ZERO server
SQL mode suppresses this behavior for 0, so that it occurs only
when NULL is inserted into the column.

This behavior is also followed on a replication slave (by the
slave SQL thread) when applying events that have been logged on
the master using the statement-based format. However, when
applying events that had been logged using the row-based format,
NO_AUTO_VALUE_ON_ZERO was
ignored, which could lead to an assertion.

To fix this issue, the value of an
AUTO_INCREMENT column is no longer generated
when applying an event that was logged using the row-based row
format, as this value is already contained in the changes
applied on the slave.
(Bug #56662)

Replication:
The BINLOG statement modified the
values of session variables, which could lead to problems with
operations such as point-in-time recovery. One such case
occurred when replaying a row-based binary log which relied on
setting foreign_key_checks =
OFF at the session level to create and populate a set
of InnoDB tables having foreign key
constraints.
(Bug #54903)

Replication:mysqlbinlog printed
USE statements to its output only
when the default database changed between events. To illustrate
how this could cause problems, suppose that a user issued the
following sequence of statements:

When played back using mysqlbinlog, the
second CREATE TABLE statement
failed with Error: No Database Selected
because the second USE statement
was not played back, due to the fact that a database other than
mydb was never selected.

This fix ensures that mysqlbinlog outputs a
USE statement whenever it reads
one from the binary log.
(Bug #50914, Bug #11758677)

Replication:
Previously, when a statement failed with a different error on
the slave than on the master, the slave SQL thread displayed a
message containing:

The error message for the master error code

The master error code

The error message for the slaves error code

The slave error code

However, the slave has no information with which to fill in any
print format specifiers for the master message, so it actually
displayed the message format string. To make it clearer that the
slave is not displaying the actual message as it appears on the
master, the slave now indicates that the master part of the
output is the message format, not the actual message. For
example, previously the slave displayed information like this:

The ucs2 character set does not support
characters outside the Basic Multilingual Plane (BMP), but
converting to ucs2 a string containing such
characters did not produce a conversion-failure warning.
(Bug #58321)

A Valgrind failure occurred in fn_format when
called from archive_discover.
(Bug #58205, Bug #11765259)

CMake did not add
LINK_LIBRARIES for
MYSQL_ADD_PLUGIN for
libmysqld.
(Bug #58158)

An assertion could be raised if the server was closing a session
at the same time the session was being killed by another thread.
(Bug #58136)

It was possible to compile mysqld with
Performance Schema support but with a dummy atomic-operations
implementation, which caused a server crash. This problem does
not affect binary distributions. It is helpful as a safety
measure for users who build MySQL from source.
(Bug #56769)

The cp1251 character set did not properly
support the Euro sign (0x88). For example,
converting a string containing this character to
utf8 resulted in '?'
rather than the utf8 Euro sign.
(Bug #56639)

Some unsigned system variables could be displayed with negative
values.
(Bug #55794)

An assertion could be raised during concurrent execution of
DROP DATABASE and
REPAIR TABLE if the drop deleted
a table's .TMD file at the same time the
repair tried to read details from the old file that was just
removed.

A problem could also occur when DROP
TABLE tried to remove all files belonging to a table
at the same time REPAIR TABLE had
just deleted the table's .TMD file.
(Bug #54486)

After compilation from source, all header files were installed
in the same directory, even those that should be installed into
subdirectories of the installation include directory.
(Bug #51925)

On FreeBSD, if mysqld was killed with a
SIGHUP signal, it could corrupt
InnoDB.ibd
files.
(Bug #51023, Bug #11758773)

An assertion could be raised if −1 was inserted into an
AUTO_INCREMENT column by a statement writing
more than one row.
(Bug #50619, Bug #11758417)

If a client supplied a user name longer than the maximum 16
characters permitted for names stored in the MySQL grant tables,
all characters were being considered significant when checking
for a match. Historically, only the first 16 characters were
used for matching; this behavior was restored.
(Bug #49752)

The my_seek() and
my_tell() functions ignored the
MY_WME flag when they returned an error,
which could cause client programs to hang.
(Bug #48451)