MySQL 5.5.6-rc がリリースされました。MySQL 5.5 シリーズとしてのはじめての RC 版です。


ダウンロードはこちらから：
http://dev.mysql.com/downloads/mysql/#downloads

----
以下チェンジログ(5.5.6-rc)






■機能の追加と変更：
* Incompatible Change: The SHA2() function now returns a
character string with the connection character set and
collation. Previously, it returned a binary string. This
is the same change made for several other encryption
functions in MySQL 5.5.3.
(Bug#54661: http://bugs.mysql.com/bug.php?id=54661)

* Overhead for the Performance Schema interface was
reduced.
(Bug#55087: http://bugs.mysql.com/bug.php?id=55087)

■バグ修正：

* Security Fix: After changing the values of the
innodb_file_format or innodb_file_per_table configuration
parameters, DDL statements could cause a server crash.
(Bug#55039: http://bugs.mysql.com/bug.php?id=55039)

* Security Fix: Joins involving a table with a unique SET
column could cause a server crash.
(Bug#54575: http://bugs.mysql.com/bug.php?id=54575)

* Security Fix: Incorrect handling of NULL arguments could
lead to a crash for IN() or CASE operations when NULL
arguments were either passed explicitly as arguments (for
IN()) or implicitly generated by the WITH ROLLUP modifier
(for IN() and CASE).
(Bug#54477: http://bugs.mysql.com/bug.php?id=54477)

* Security Fix: A malformed argument to the BINLOG
statement could result in Valgrind warnings or a server
crash.
(Bug#54393: http://bugs.mysql.com/bug.php?id=54393)

* Security Fix: Use of TEMPORARY InnoDB tables with
nullable columns could cause a server crash.
(Bug#54044: http://bugs.mysql.com/bug.php?id=54044)

* Security Fix: Using EXPLAIN with queries of the form
SELECT ... UNION ... ORDER BY (SELECT ... WHERE ...)
could cause a server crash.
(Bug#52711: http://bugs.mysql.com/bug.php?id=52711)

* Incompatible Change: Replication: As of MySQL 5.5.6, handling
of CREATE TABLE IF NOT EXISTS ... SELECT statements has been
changed for the case that the destination table already
exists:

+ Previously, for CREATE TABLE IF NOT EXISTS ... SELECT,
MySQL produced a warning that the table exists, but
inserted the rows and wrote the statement to the binary
log anyway. By contrast, CREATE TABLE ... SELECT (without
IF NOT EXISTS) failed with an error, but MySQL inserted
no rows and did not write the statement to the binary
log.

+ MySQL now handles both statements the same way when the
destination table exists, in that neither statement
inserts rows or is written to the binary log. The
difference between them is that MySQL produces a warning
when IF NOT EXISTS is present and an error when it is
not.

This change in handling of IF NOT EXISTS results in an
incompatibility for statement-based replication from a MySQL
5.1 master with the original behavior and a MySQL 5.5 slave
with the new behavior. Suppose that CREATE TABLE IF NOT EXISTS
... SELECT is executed on the master and the destination table
exists. The result is that rows are inserted on the master but
not on the slave. (Row-based replication does not have this
problem.)
To address this issue, statement-based binary logging for
CREATE TABLE IF NOT EXISTS ... SELECT is changed in MySQL 5.1
as of 5.1.51:

+ If the destination table does not exist, there is no
change: The statement is logged as is.

+ If the destination table does exist, the statement is
logged as the equivalent pair of CREATE TABLE IF NOT
EXISTS and INSERT ... SELECT statements. (If the SELECT
in the original statement is preceded by IGNORE or
REPLACE, the INSERT becomes INSERT IGNORE or REPLACE,
respectively.)

This change provides forward compatibility for statement-based
replication from MySQL 5.1 to 5.5 because when the destination
table exists, the rows will be inserted on both the master and
slave. To take advantage of this compatibility measure, the
5.1 server must be at least 5.1.51 and the 5.5 server must be
at least 5.5.6.
To upgrade an existing 5.1-to-5.5 replication scenario,
upgrade the master first to 5.1.51 or higher. Note that this
differs from the usual replication upgrade advice of upgrading
the slave first.
A workaround for applications that wish to achieve the
original effect (rows inserted regardless of whether the
destination table exists) is to use CREATE TABLE IF NOT EXISTS
and INSERT ... SELECT statements rather than CREATE TABLE IF
NOT EXISTS ... SELECT statements.
Along with the change just described, the following related
change was made: Previously, if an existing view was named as
the destination table for CREATE TABLE IF NOT EXISTS ...
SELECT, rows were inserted into the underlying base table and
the statement was written to the binary log. As of MySQL
5.1.51 and 5.5.6, nothing is inserted or logged.
(Bug#47442: http://bugs.mysql.com/bug.php?id=47442,
Bug#47132: http://bugs.mysql.com/bug.php?id=47132,
Bug#48814: http://bugs.mysql.com/bug.php?id=48814,
Bug#49494: http://bugs.mysql.com/bug.php?id=49494)

* Incompatible Change: Several changes were made to Performance
Schema tables:

+ The SETUP_OBJECTS table was removed.

+ The PROCESSLIST table was renamed to THREADS.

+ The EVENTS_WAITS_SUMMARY_BY_EVENT_NAME table was renamed
to EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME.

(Bug#55416: http://bugs.mysql.com/bug.php?id=55416)

* Incompatible Change: Handling of warnings and errors
during stored program execution was problematic:

+ If one statement generated several warnings or
errors, only the handler for the first was
activated, even if another might be more
appropriate.

+ Warning or error information could be lost.

(Bug#36185: http://bugs.mysql.com/bug.php?id=36185,
Bug#5889: http://bugs.mysql.com/bug.php?id=5889,
Bug#9857: http://bugs.mysql.com/bug.php?id=9857,
Bug#23032: http://bugs.mysql.com/bug.php?id=23032)

* Important Change: Replication: The LOAD DATA INFILE
statement is now considered unsafe for statement-based
replication. When using statement-based logging mode, the
statement now produces a warning; when using mixed-format
logging, the statement is made using the row-based
format.
(Bug#34283: http://bugs.mysql.com/bug.php?id=34283)

* Partitioning: With innodb_thread_concurrency = 1, ALTER TABLE
... REORGANIZE PARTITION and SELECT could deadlock. There were
unreleased latches in the ALTER TABLE ... REORGANIZE PARTITION
thread which were needed by the SELECT thread to be able to
continue. (Bug#54747: http://bugs.mysql.com/bug.php?id=54747)

* Partitioning: An ALTER TABLE ... ADD PARTITION statement
run concurrently with a read lock caused spurious
ER_TABLE_EXISTS and ER_NO_SUCH_TABLE errors on subsequent
attempts.
(Bug#53676: http://bugs.mysql.com/bug.php?id=53676)
See also
Bug#53770: http://bugs.mysql.com/bug.php?id=53770.

* Partitioning: UPDATE and INSERT statements affecting
partitioned tables performed poorly when using row-based
replication.
(Bug#52517: http://bugs.mysql.com/bug.php?id=52517)

* Partitioning: INSERT ON DUPLICATE KEY UPDATE statements
performed poorly on tables having many partitions. This
was because the handler function for reading a row from a
specific index was not optimized in the partitioning
handler.
(Bug#52455: http://bugs.mysql.com/bug.php?id=52455)

* Partitioning: ALTER TABLE ... TRUNCATE PARTITION, when
called concurrently with transactional DML on the table,
was executed immediately and did not wait for the
concurrent transaction to release locks. As a result, the
ALTER TABLE statement was written into the binary log
before the DML statement, which led to replication
failures when using row-based logging.
(Bug#49907: http://bugs.mysql.com/bug.php?id=49907)
See also
Bug#42643: http://bugs.mysql.com/bug.php?id=42643.

* Partitioning: When the storage engine used to create a
partitioned table was disabled, attempting to drop the
table caused the server to crash.
(Bug#46086: http://bugs.mysql.com/bug.php?id=46086)

* Replication: When using the row-based logging format, a
failed CREATE TABLE ... SELECT statement was written to
the binary log, causing replication to break if the
failed statement was later re-run on the master. In such
cases, a DROP TABLE ... IF EXIST statement is now logged
in the event that a CREATE TABLE ... SELECT fails.
(Bug#55625: http://bugs.mysql.com/bug.php?id=55625)

* Replication: When using the row-based logging format, a
SET PASSWORD statement was written to the binary log
twice.
(Bug#55452: http://bugs.mysql.com/bug.php?id=55452)

* Replication: When closing temporary tables, after the
session connection was already closed, if the writing of
the implicit DROP TABLE statement into the binary log
failed, it was possible for the resulting error to be
mishandled, triggering an assertion.
(Bug#55387: http://bugs.mysql.com/bug.php?id=55387)

* Replication: Executing SHOW BINLOG EVENTS increased the
value of max_allowed_packet applying to the session that
executed the statement.
(Bug#55322: http://bugs.mysql.com/bug.php?id=55322)

* Replication: Setting binlog_format = ROW then creating
and then dropping a temporary table led an assertion.
(Bug#54925: http://bugs.mysql.com/bug.php?id=54925)

* Replication: When using mixed-format replication, changes
made to a non-transactional temporary table within a
transaction were not written into the binary log when the
transaction was rolled back. This could lead to a failure
in replication if the temporary table was used again
afterwards.
(Bug#54872: http://bugs.mysql.com/bug.php?id=54872)
See also
Bug#53259: http://bugs.mysql.com/bug.php?id=53259.

* Replication: If binlog_format was explicitly switched
from STATEMENT to ROW following the creation of a
temporary table, then on disconnection the master failed
to write the expected DROP TEMPORARY TABLE statement into
the binary log. As a consequence, temporary tables (and
their corresponding files) accumulated as this scenario
was repeated.
(Bug#54842: http://bugs.mysql.com/bug.php?id=54842)
See also
Bug#52616: http://bugs.mysql.com/bug.php?id=52616.

* Replication: If the SQL thread was started while the I/O
thread was performing rotation of the relay log, the 2
threads could begin to race for the same I/O cache,
leading to a crash of the server.
(Bug#54509: http://bugs.mysql.com/bug.php?id=54509)
See also
Bug#50364: http://bugs.mysql.com/bug.php?id=50364.

* Replication: Two related issues involving temporary
tables and transactions were introduced by a fix made in
MySQL 5.1.37:

1. When a temporary table was created or dropped within
a transaction, any failed statement that following
the CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE
statement triggered a rollback, which caused the
slave diverge from the master.

2. When a CREATE TEMPORARY TABLE ... SELECT * FROM ...
statement was executed within a transaction in which
only tables using transactional storage engines were
used and the transaction was rolled back at the end,
the changes---including the creation of the
temporary table---were not written to the binary
log.

The current fix restores the correct behavior in both of
these cases.
(Bug#53560: http://bugs.mysql.com/bug.php?id=53560)
This regression was introduced by
Bug#43929: http://bugs.mysql.com/bug.php?id=43929.

* Replication: The value of
binlog_direct_non_transactional_updates had no effect on
statements mixing transactional tables and
nontransactional tables, or mixing temporary tables and
nontransactional tables.
As part of the fix for this issue, updates to temporary
tables are now handled as transactional or
nontransactional according to their storage engine types.
(In effect, the current fix reverts a change made
previously as part of the fix for
Bug#53259: http://bugs.mysql.com/bug.php?id=53259.)
In addition, unsafe mixed statements (that is, statements
which access transactional table as well nontransactional
or temporary tables, and write to any of them) are now
handled as transactional when the statement-based logging
format is in use.
(Bug#53452: http://bugs.mysql.com/bug.php?id=53452)
See also
Bug#51894: http://bugs.mysql.com/bug.php?id=51894.

* Replication: When binlog_format=STATEMENT, any statement
that is flagged as being unsafe, possibly causing the
slave to go out of sync, generates a warning. This
warning is written to the server log, the warning count
is returned to the client in the server's response, and
the warnings are accessible through SHOW WARNINGS.
The current bug affects only the counts for warnings to
the client and that are visible through SHOW WARNINGS; it
does not affect which warnings are written to the log.
The current issue came about because the fix for an
earlier issue caused warnings for substatements to be
cleared whenever a new substatement was started. However,
this suppressed warnings for unsafe statements in some
cases. Now, such warnings are no longer cleared.
(Bug#50312: http://bugs.mysql.com/bug.php?id=50312)
This regression was introduced by
Bug#36649: http://bugs.mysql.com/bug.php?id=36649.

* Replication: Replication could break if a transaction
involving both transactional and nontransactional tables
was rolled back to a savepoint. It broke if a concurrent
connection tried to drop a transactional table which was
locked after the savepoint was set. This DROP TABLE
completed when ROLLBACK TO SAVEPOINT was executed because
the lock on the table was dropped by the transaction.
When the slave later tried to apply the binary log
events, it would fail because the table had already been
dropped.
(Bug#50124: http://bugs.mysql.com/bug.php?id=50124)

* Replication: When CURRENT_USER() or CURRENT_USER was used
to supply the name and host of the affected user or of
the definer in any of the statements DROP USER, RENAME
USER, GRANT, REVOKE, and ALTER EVENT, the reference to
CURRENT_USER() or CURRENT_USER was not expanded when
written to the binary log. This resulted in
CURRENT_USER() or CURRENT_USER being expanded to the user
and host of the slave SQL thread on the slave, thus
breaking replication. Now CURRENT_USER() and CURRENT_USER
are expanded prior to being written to the binary log in
such cases, so that the correct user and host are
referenced on both the master and the slave.
(Bug#48321: http://bugs.mysql.com/bug.php?id=48321)

* After an RPM installation mysqld would be started with the
root, rather than the mysql user.
(Bug#56574: http://bugs.mysql.com/bug.php?id=56574)

* An assertion was raised if (1) an InnoDB table was created
using CREATE TABLE ... SELECT where the query used an
INFORMATION_SCHEMA table and a view existed in the database;
or (2) sny statement that modified an InnoDB table had a
subquery referencing an INFORMATION_SCHEMA table.
(Bug#55973: http://bugs.mysql.com/bug.php?id=55973)

* CMake would produce bad dependencies for the
sql/lex_hash.h file during configuration.
(Bug#55842: http://bugs.mysql.com/bug.php?id=55842)

* mysql_upgrade did not handle the --ssl option properly.
(Bug#55672: http://bugs.mysql.com/bug.php?id=55672)

* Using MIN() or MAX() on a column containing the maximum
TIME value caused a server crash.
(Bug#55648: http://bugs.mysql.com/bug.php?id=55648)

* Incorrect handling of user variable assignments as
subexpressions could lead to incorrect results or server
crashes.
(Bug#55615: http://bugs.mysql.com/bug.php?id=55615)

* The default compiler options used for Mac OS X 10.5 would
be set incorrectly.
(Bug#55601: http://bugs.mysql.com/bug.php?id=55601)

* The server was not checking for errors generated during
the execution of Item::val_xxx() methods when copying
data to a group, order, or distinct temp table's row.
(Bug#55580: http://bugs.mysql.com/bug.php?id=55580)

* ORDER BY clauses that included user variable expressions
could cause a debug assertion to be raised.
(Bug#55565: http://bugs.mysql.com/bug.php?id=55565)

* The InnoDB storage engine was not included in the default
installation when using the configure script.
(Bug#55547: http://bugs.mysql.com/bug.php?id=55547)

* SHOW CREATE TRIGGER took a stronger metadata lock than
required. This caused the statement to be blocked
unnecessarily. For example, LOCK TABLES ... WRITE in one
session blocked SHOW CREATE TRIGGER in another session.
Also, a SHOW CREATE TRIGGER statement issued inside a
transaction did not release its metadata locks at the end
of statement execution. Consequently, SHOW CREATE TRIGGER
was able to block other sessions from accessing the table
(for example, using ALTER TABLE).
(Bug#55498: http://bugs.mysql.com/bug.php?id=55498)

* A single-table DELETE ordered by a column that had a
hash-type index could raise an assertion or cause a
server crash.
(Bug#55472: http://bugs.mysql.com/bug.php?id=55472)

* A call to mysql_library_init() following a call to
mysql_library_end() caused a client crash.
(Bug#55345: http://bugs.mysql.com/bug.php?id=55345)

* A statement that was aborted by KILL QUERY while it
waited on a metadata lock could raise an assertion in
debug builds, or send OK to the client instead of
ER_QUERY_INTERRUPTED in regular builds.
(Bug#55223: http://bugs.mysql.com/bug.php?id=55223)

* The mysql_config tool would not output the requirement
for the aio library for mysqld-libs.
(Bug#55215: http://bugs.mysql.com/bug.php?id=55215)

* GROUP BY operations used max_sort_length inconsistently.
(Bug#55188: http://bugs.mysql.com/bug.php?id=55188)

* The Windows MSI installer would fail to preserve custom
settings, such as the configured data directory, during
installation.
(Bug#55169: http://bugs.mysql.com/bug.php?id=55169)

* IF() with a subquery argument could raise a debug assertion
for debug builds under some circumstances.
(Bug#55077: http://bugs.mysql.com/bug.php?id=55077)

* Building MySQL on Solaris 8 x86 failed when using Sun
Studio due to gcc inline assembler code.
(Bug#55061: http://bugs.mysql.com/bug.php?id=55061)

* When upgrading an existing install with an RPM on Linux,
the MySQL server might not have been restarted properly.
This was due to a naming conflict when upgrading from a
community named RPM. Previous installations are now
correctly removed, and the MySQL init script are
recreated and then start the MySQL server as normal.
(Bug#55015: http://bugs.mysql.com/bug.php?id=55015)

* The thread_concurrency system variable was unavailable on
non-Solaris systems.
(Bug#55001: http://bugs.mysql.com/bug.php?id=55001)

* mysqld_safe contained a syntax error that prevented it
from restarting the server.
(Bug#54991: http://bugs.mysql.com/bug.php?id=54991)

* If audit plugins were installed that were interested in
MYSQL_AUDIT_GENERAL_CLASS events and the general query
log was disabled, failed INSTALL PLUGIN or UNINSTALL
PLUGIN statements caused a server crash.
(Bug#54989: http://bugs.mysql.com/bug.php?id=54989)

* A SHOW CREATE TABLE statement issued inside a transaction
did not release its metadata locks at the end of
statement execution. Consequently, SHOW CREATE TABLE was
able to block other sessions from accessing the table
(for example, using ALTER TABLE).
(Bug#54905: http://bugs.mysql.com/bug.php?id=54905)

* INFORMATION_SCHEMA.ENGINES and SHOW ENGINES described
MyISAM as the default storage engine, but this is not
true as of MySQL 5.5.5.
(Bug#54832: http://bugs.mysql.com/bug.php?id=54832)

* The MERGE storage engine tried to use memory mapping on
the underlying MyISAM tables even on platforms that do
not support it and even when myisam_use_mmap was
disabled. This led to a hang for INSERT INTO ... SELECT
FROM statements that selected from a MyISAM table into a
MERGE table that contained the same MyISAM table.
(Bug#54811: http://bugs.mysql.com/bug.php?id=54811,
Bug#50788: http://bugs.mysql.com/bug.php?id=50788)

* Incorrect error handling could result in an OPTIMIZE
TABLE crash.
(Bug#54783: http://bugs.mysql.com/bug.php?id=54783)

* Performance Schema event collection for a thread could
"leak" from one connection to another if the thread was
used for one connection, then cached, then reused for
another connection.
(Bug#54782: http://bugs.mysql.com/bug.php?id=54782)

* Some memory used for InnoDB asynchronous I/O was not freed at
shutdown. (Bug#54764: http://bugs.mysql.com/bug.php?id=54764)

* In debug builds, an assertion could be raised when the
server tried to send an OK packet to the client after
having failed to detect errors during processing of the
WHERE condition of an UPDATE statement.
(Bug#54734: http://bugs.mysql.com/bug.php?id=54734)

* In a slave SQL thread or Event Scheduler thread, the
SLEEP() function could not sleep more than five seconds.
(Bug#54729: http://bugs.mysql.com/bug.php?id=54729)

* Implementation of the 64-bit dulint structure in InnoDB
was not optimized for 64-bit processors, resulting in
excessive storage and reduced performance.
(Bug#54728: http://bugs.mysql.com/bug.php?id=54728)

* The output from the SHOW ENGINE INNODB STATUS command now
includes information about "spin rounds" for RW-locks
(both shared and exclusive locks).
(Bug#54726: http://bugs.mysql.com/bug.php?id=54726)

* SET sql_select_limit = 0 did not work.
(Bug#54682: http://bugs.mysql.com/bug.php?id=54682)

* An ALTER TABLE statement could convert an InnoDB
compressed table (with row_format=compressed) back to an
uncompressed table (with row_format=compact).
(Bug#54679: http://bugs.mysql.com/bug.php?id=54679)

* Assignments of the PASSWORD() or OLD_PASSWORD() function
to a user variable did not preserve the character set of
the function return value.
(Bug#54668: http://bugs.mysql.com/bug.php?id=54668)

* A signal-handler redefinition for SIGUSR1 was removed.
The redefinition could cause the server to encounter a
kernel deadlock on Solaris when there are many active
threads. Other POSIX platforms might also be affected.
(Bug#54667: http://bugs.mysql.com/bug.php?id=54667)

* InnoDB could issue an incorrect message on startup, if
tables were created under the setting
innodb_file_per_table=ON and the server was restarted
under the setting innodb_file_per_table=OFF. The message
was of the form InnoDB: Warning: allocated tablespace n,
old maximum was 0.
(Bug#54658: http://bugs.mysql.com/bug.php?id=54658)

* Queries that named view columns in a GROUP BY clause
could cause a server crash.
(Bug#54515: http://bugs.mysql.com/bug.php?id=54515)

* Performance Schema displayed spurious startup error
messages when the server was run in bootstrap mode.
(Bug#54467: http://bugs.mysql.com/bug.php?id=54467)

* For distributions built with cmake rather than the GNU
autotools, mysql lacked pager support.
(Bug#54466: http://bugs.mysql.com/bug.php?id=54466)

* The server failed to disregard sort order for some
zero-length tuples, leading to an assertion failure.
(Bug#54459: http://bugs.mysql.com/bug.php?id=54459)

* The default value of myisam_max_extra_sort_file_size
(http://dev.mysql.com/doc/refman/5.0/en/server-system-var
iables.html#sysvar_myisam_max_extra_sort_file_size) could
be higher than the maximum accepted value, leading to
warnings upon the server start.
(Bug#54457: http://bugs.mysql.com/bug.php?id=54457)

* The database server could crash when renaming a table
that had active transactions. (This issue only affected
the database server when built for debugging.)
(Bug#54453: http://bugs.mysql.com/bug.php?id=54453)

* The server could crash during the recovery phase of
startup, if it previously crashed while inserting BLOB or
other large columns that use off-page storage into an
InnoDB table created with ROW_FORMAT=REDUNDANT or
ROW_FORMAT=COMPACT.
(Bug#54408: http://bugs.mysql.com/bug.php?id=54408)

* Errors during processing of WHERE conditions in HANDLER
... READ statements were not detected, so the handler
code still tried to send EOF to the client, raising an
assertion.
(Bug#54401: http://bugs.mysql.com/bug.php?id=54401)

* If a session tried to drop a database containing a table
opened with HANDLER in another session, any DATABASE
statement (CREATE, DROP, ALTER) executed by that session
produced a deadlock.
(Bug#54360: http://bugs.mysql.com/bug.php?id=54360)

* For an InnoDB table created with ROW_FORMAT=COMPRESSED or
ROW_FORMAT=DYNAMIC, a query using the READ UNCOMMITTED
isolation level could cause the server to stop with an
assertion error, if BLOB or other large columns that use
off-page storage were being inserted at the same time.
(Bug#54358: http://bugs.mysql.com/bug.php?id=54358)

* Fast index creation in the InnoDB Plugin could fail,
leaving the new secondary index corrupted.
(Bug#54330: http://bugs.mysql.com/bug.php?id=54330)

* For distributions built with cmake rather than the GNU
autotools, some scripts were built without the execute
bit set.
(Bug#54129: http://bugs.mysql.com/bug.php?id=54129)

* INSERT IGNORE INTO ... SELECT statements could cause a
debug assertion to be raised.
(Bug#54106: http://bugs.mysql.com/bug.php?id=54106)

* A client could supply data in chunks to a prepared
statement parameter other than of type TEXT or BLOB using
the mysql_stmt_send_long_data() C API function (or
COM_STMT_SEND_LONG_DATA command). This led to a crash
because other data types are not valid for long data.
(Bug#54041: http://bugs.mysql.com/bug.php?id=54041)

* mysql_secure_installation did not properly identify local
accounts and could incorrectly remove nonlocal root
accounts.
(Bug#54004: http://bugs.mysql.com/bug.php?id=54004)

* A client with automatic reconnection enabled saw the
error message Lost connection to MySQL server during
query if the connection was lost between the
mysql_stmt_prepare() and mysql_stmt_execute() C API
functions. However, mysql_stmt_errno() returned 0, not
the corresponding error number 2013.
(Bug#53899: http://bugs.mysql.com/bug.php?id=53899)

* INFORMATION_SCHEMA.COLUMNS reported incorrect precision
for BIGINT UNSIGNED columns.
(Bug#53814: http://bugs.mysql.com/bug.php?id=53814)

* If a session executing TRUNCATE TABLE on an InnoDB table
was killed during open_tables(), an assertion could be
raised.
(Bug#53757: http://bugs.mysql.com/bug.php?id=53757)

* Transactions could be incorrectly committed during
recovery, rather than rolled back, if the server crashed
and was restarted after performing ALTER TABLE...ADD
PRIMARY KEY on an InnoDB table, or some other operation
that involves copying the entire table.
(Bug#53756: http://bugs.mysql.com/bug.php?id=53756)

* The patch for
Bug#36569: http://bugs.mysql.com/bug.php?id=36569 caused
performance regressions and incorrect execution of some
UPDATE statments.
(Bug#53737: http://bugs.mysql.com/bug.php?id=53737,
Bug#53742: http://bugs.mysql.com/bug.php?id=53742)

* Missing Performance Schema tables were not reported in
the error log at server startup.
(Bug#53617: http://bugs.mysql.com/bug.php?id=53617)

* mysql_upgrade could incorrectly remove TRIGGER
privileges.
(Bug#53613: http://bugs.mysql.com/bug.php?id=53613)

* SHOW ENGINE PERFORMANCE_SCHEMA STATUS underreported the
amount of memory allocated by Performance Schema.
(Bug#53566: http://bugs.mysql.com/bug.php?id=53566)

* Portability problems in SHOW STATUS could lead to
incorrect results on some platforms.
(Bug#53493: http://bugs.mysql.com/bug.php?id=53493)

* Builds of MySQL generated a large number of warnings.
(Bug#53445: http://bugs.mysql.com/bug.php?id=53445)

* Performance Schema header files were not installed in the
correct directory.
(Bug#53255: http://bugs.mysql.com/bug.php?id=53255)

* The server could crash when processing subqueries with
empty results.
(Bug#53236: http://bugs.mysql.com/bug.php?id=53236)

* Misimplementation of the os_fast_mutex_trylock() function
in InnoDB resulted in unnecessary blocking and reduced
performance.
(Bug#53204: http://bugs.mysql.com/bug.php?id=53204)

* With lower_case_table_names set to a nonzero value,
searches for table or database names in
INFORMATION_SCHEMA tables could produce incorrect
results.
(Bug#53095: http://bugs.mysql.com/bug.php?id=53095)

* Use of uint in typelib.h caused compilation problems in
Windows. This was changed to unsigned int.
(Bug#52959: http://bugs.mysql.com/bug.php?id=52959)

* The mysql-debug.pdb supplied with releases did not match
the corresponding mysqld.exe.
(Bug#52850: http://bugs.mysql.com/bug.php?id=52850)

* The PERFORMANCE_SCHEMA database was not correctly created and
populated on Windows.
(Bug#52809: http://bugs.mysql.com/bug.php?id=52809)

* The large_pages system variable was tied to the
--large-files command-line option, not the --large-pages
option.
(Bug#52716: http://bugs.mysql.com/bug.php?id=52716)

* Attempts to access a nonexistent table in the
performance_schema database resulted in a misleading
error message.
(Bug#52586: http://bugs.mysql.com/bug.php?id=52586)

* The ABI check for MySQL failed to compile with gcc 4.5.
(Bug#52514: http://bugs.mysql.com/bug.php?id=52514)

* Performance Schema could enter an infinite loop if
required to create a large number of mutex instances.
(Bug#52502: http://bugs.mysql.com/bug.php?id=52502)

* mysql_secure_installation sometimes failed to locate the
mysql client.
(Bug#52274: http://bugs.mysql.com/bug.php?id=52274)

* InnoDB could not create tables that used the utf32
character set.
(Bug#52199: http://bugs.mysql.com/bug.php?id=52199)

* Some queries involving GROUP BY and a function that
returned DATE raised a debug assertion.
(Bug#52159: http://bugs.mysql.com/bug.php?id=52159)

* If a symbolic link was used in a file path name, the
Performance Schema did not resolve all file io events to
the same name.
(Bug#52134: http://bugs.mysql.com/bug.php?id=52134)

* PARTITION BY KEY on a utf32 ENUM column raised a
debugging assertion.
(Bug#52121: http://bugs.mysql.com/bug.php?id=52121)

* A pending FLUSH TABLES tbl_list WITH READ LOCK statement
unnecessarily aborted transactions.
(Bug#52117: http://bugs.mysql.com/bug.php?id=52117)

* FLUSH TABLES WITH READ LOCK in one session and FLUSH
TABLES tbl_list WITH READ LOCK in another session were
mutually exclusive.
(Bug#52044: http://bugs.mysql.com/bug.php?id=52044)

* Reading a ucs2 data file with LOAD DATA INFILE was
subject to three problems. 1) Incorrect parsing of the
file as ucs2 data, resulting in incorrect length of the
parsed string. This is fixed by truncating the invalid
trailing bytes (incomplete multibyte characters) when
reading from the file. 2) Reads from a proper ucs2 file
did not recognize newline characters. This is fixed by
first checking whether a byte is a newline (or any other
special character) before reading it as a part of a
multibyte character. 3) When using user variables to hold
column data, the character set of the user variable was
set incorrectly to the database charset. This is fixed by
setting it to the character set specified in the LOAD
DATA INFILE statement, if any.
(Bug#51876: http://bugs.mysql.com/bug.php?id=51876)

* XA START had a race condition that could cause a server
crash.
(Bug#51855: http://bugs.mysql.com/bug.php?id=51855)

* The results of some ORDER BY ... DESC queries were sorted
incorrectly.
(Bug#51431: http://bugs.mysql.com/bug.php?id=51431)

* Index Merge between three indexes could return incorrect
results.
(Bug#50389: http://bugs.mysql.com/bug.php?id=50389)

* MIN() and MAX() returned incorrect results for DATE
columns if the set of values included '0000-00-00'.
(Bug#49771: http://bugs.mysql.com/bug.php?id=49771)

* Searches in INFORMATION_SCHEMA tables for rows matching a
nonexistent database produced an error instead of an
empty query result.
(Bug#49542: http://bugs.mysql.com/bug.php?id=49542)

* DROP DATABASE failed if there was a TEMPORARY table with
the same name as a non-TEMPORARY table in the database.
(Bug#48067: http://bugs.mysql.com/bug.php?id=48067)

* Performing large numbers of RENAME TABLE statements
caused excessive memory use.
(Bug#47991: http://bugs.mysql.com/bug.php?id=47991)

* An assertion occurred in ha_myisammrg.cc line 1137:
DBUG_ASSERT(this->file->children_attached);
The problem was found while running RQG tests and the
assertion occurred during REPAIR, OPTIMIZE, and ANALYZE
operations.
(Bug#47633: http://bugs.mysql.com/bug.php?id=47633)

* The optimize method of the ARCHIVE storage engine did not
preserve the FRM embedded in the ARZ file when rewriting
the ARZ file for optimization. This meant an ARCHIVE
table that had been optimized could not be discovered.
The ARCHIVE engine stores the FRM in the ARZ file so it
can be transferred from machine to machine without also
needing to copy the FRM file. The engine subsequently
restores the embedded FRM during discovery.
(Bug#45377: http://bugs.mysql.com/bug.php?id=45377)

* With character_set_connection set to utf16 or utf32,
CREATE TABLE t1 AS SELECT HEX() ... caused a server
crash.
(Bug#45263: http://bugs.mysql.com/bug.php?id=45263)

* The my_like_range_xxx() functions returned badly formed
maximum strings for Asian character sets, which caused
problems for storage engines.
(Bug#45012: http://bugs.mysql.com/bug.php?id=45012)

* A debugging assertion could be raised after a write
failure to a closed socket.
(Bug#42496: http://bugs.mysql.com/bug.php?id=42496)

* Enumeration plugin variables were subject to a type
casting error, causing inconsistent results between
different platforms.
(Bug#42144: http://bugs.mysql.com/bug.php?id=42144)

* Sort-index_merge for join tables other than the first
table used excessive memory.
(Bug#41660: http://bugs.mysql.com/bug.php?id=41660)

* The mechanism that checks if there is enough space for
redo logs was improved, reducing the chance of
encountering this message: ERROR: the age of the last
checkpoint is x, which exceeds the log group capacity y.
(Bug#39168: http://bugs.mysql.com/bug.php?id=39168)

* Rows inserted in a table by one session were not
immediately visible to another session that queried the
table, even if the insert had committed.
(Bug#37521: http://bugs.mysql.com/bug.php?id=37521)

* Statements of the form UPDATE ... WHERE ... ORDER BY used
a filesort even when not required.
(Bug#36569: http://bugs.mysql.com/bug.php?id=36569)
See also
Bug#53737: http://bugs.mysql.com/bug.php?id=53737,
Bug#53742: http://bugs.mysql.com/bug.php?id=53742.

* Reading from a temporary MERGE table, with two
non-temporary child MyISAM tables, resulted in the error:
ERROR 1168 (HY000): Unable to open underlying table which is
differently defined or of non-MyISAM type or doesn't exist
(Bug#36171: http://bugs.mysql.com/bug.php?id=36171)

* safemalloc was excessively slow under certain conditions
and has been removed. The --skip-safemalloc server option
has also been removed, and the --with-debug=full
configuration option is no different from --with-debug.
(Bug#34043: http://bugs.mysql.com/bug.php?id=34043)

* Threads that were calculating the estimated number of
records for a range scan did not respond to the KILL
statement. That is, if a range join type is possible
(even if not selected by the optimizer as a join type of
choice and thus not shown by EXPLAIN), the query in the
statistics state (shown by the SHOW PROCESSLIST) did not
respond to the KILL statement.
(Bug#25421: http://bugs.mysql.com/bug.php?id=25421)

* Problems in the atomic operations implementation could
lead to server crashes.
(Bug#22320: http://bugs.mysql.com/bug.php?id=22320,
Bug#52261: http://bugs.mysql.com/bug.php?id=52261)

* Improved performance and scalability on Windows systems,
especially for Windows Vista and higher. Re-enabled the
use of atomic instructions on Windows systems. For
Windows Vista and higher, reduced the number of event
handles used. To compile on Windows systems now requires
Windows SDK v6.0 or later; either upgrade to Visual
Studio 2008 or 2010, or for Visual Studio 2005, install
Windows SDK Update for Windows Vista.
(Bug#22268: http://bugs.mysql.com/bug.php?id=22268)