MySQL 6.0.6-alpha がリリースされました。　このリリースは、現在のMySQL のもっとも先端のメジャーバージョンである バージョン 6.0 系列の、最新アルファ版リリースです。
MySQL 6.0 については、http://www.mysql.com/mysql60/ をご覧ください。

本バージョンから標準で Maria ストレージエンジンが入りました！

その他、数多くの Incompatibleな変更が加えられています。ガンガンに開発が進んでいる様子で良いですね。


-----------------
以下チェンジログ

■機能の追加と変更(6.0.6)
* Important Change: Incompatible Change: The FEDERATED storage
engine is now disabled by default in binary distributions. The
engine is still available and can be enabled by starting the
server with the --federated option.
(Bug#37069: http://bugs.mysql.com/37069)

* Incompatible Change: The engines column in the
mysql.online_backup table has been renamed to drivers to better
reflect its contents.
(Bug#34965: http://bugs.mysql.com/34965)

* Incompatible Change: A change has been made to the way that
the server handles prepared statements. This affects prepared
statements processed at the SQL level (using the PREPARE
statement) and those processed using the binary client-server
protocol (using the mysql_stmt_prepare() C API function).
Previously, changes to metadata of tables or views referred to
in a prepared statement could cause a server crash when the
statement was next executed, or perhaps an error at execute time
with a crash occurring later. For example, this could happen
after dropping a table and recreating it with a different
definition. Now metadata changes to tables or views referred to
by prepared statements are detected and cause automatic
repreparation of the statement when it is next executed.
Metadata changes occur for DDL statements such as those that
create, drop, alter, rename, or truncate tables, or that
analyze, optimize, or repair tables. Repreparation also occurs
after referenced tables or views are flushed from the table
definition cache, either implicitly to make room for new entries
in the cache, or explicitly due to FLUSH TABLES. Repreparation
is automatic, but to the extent that it occurs, performance of
prepared statements is diminished. Table content changes (for
example, with INSERT or UPDATE) do not cause repreparation, nor
do SELECT statements. An incompatibility with previous versions
of MySQL is that a prepared statement may now return a different
set of columns or different column types from one execution to
the next. For example, if the prepared statement is SELECT *
FROM t1, altering t1 to contain a different number of columns
causes the next execution to return a number of columns
different from the previous execution. Older versions of the
client library cannot handle this change in behavior. For
applications that use prepared statements with the new server,
an upgrade to the new client library is strongly recommended.
Along with this change to statement repreparation, the default
value of the table_definition_cache system variable has been
increased from 128 to 256. The purpose of this increase is to
lessen the chance that prepared statements will need
repreparation due to referred-to tables/views having been
flushed from the cache to make room for new entries. A new
status variable, Com_stmt_reprepare, has been introduced to
track the number of repreparations.
(Bug#27420: http://bugs.mysql.com/27420,
Bug#27430: http://bugs.mysql.com/27430,
Bug#27690: http://bugs.mysql.com/27690)

* Important Change: Some changes were made to CHECK TABLE ...
FOR UPGRADE and REPAIR TABLE with respect to detection and
handling of tables with incompatible .frm files (files created
with a different version of the MySQL server). These changes
also affect mysqlcheck because that program uses CHECK TABLE and
REPAIR table, and thus also mysql_upgrade because that program
invokes mysqlcheck. + If your table was created by a different
version of the MySQL server than the one you are currently
running, CHECK TABLE ... FOR UPGRADE indicates that the table
has an .frm file with an incompatible version. In this case, the
result set returned by CHECK TABLE contains a line with a
Msg_type value of error and a Msg_text value of Table upgrade
required. Please do "REPAIR TABLE `tbl_name`" to fix it! +
REPAIR TABLE without USE_FRM upgrades the .frm file to the
current version. + If you use REPAIR TABLE ...USE_FRM and your
table was created by a different version of the MySQL server
than the one you are currently running, REPAIR TABLE will not
attempt to repair the table. In this case, the result set
returned by REPAIR TABLE contains a line with a Msg_type value
of error and a Msg_text value of Failed repairing incompatible
.FRM file. Previously, use of REPAIR TABLE ...USE_FRM with a
table created by a different version of the MySQL server risked
the loss of all rows in the table.
(Bug#36055: http://bugs.mysql.com/36055)

* On Unix, it is now possible for the output file for BACKUP
DATABASE to be an existing FIFO.
(Bug#37012: http://bugs.mysql.com/37012)

* mysql_upgrade now has a --tmpdir option to enable the location
of temporary files to be specified.
(Bug#36469: http://bugs.mysql.com/36469)

* mysqldump now adds the LOCAL qualifier to the FLUSH TABLES
statement that is sent to the server when the --master-data
option is enabled. This prevents the FLUSH TABLES statement from
replicating to slaves, which is disadvantageous because it would
cause slaves to block while the statement executes.
(Bug#35157: http://bugs.mysql.com/35157)
See also Bug#38303: http://bugs.mysql.com/38303

* The use of the SQL_CACHE and SQL_NO_CACHE options in SELECT
statements now is checked more restrictively: 1) Previously,
both options could be given in the same statement. This is no
longer true; only one can be given. 2) Previously, these options
could be given in SELECT statements that were not at the
top-level. This is no longer true; the options are disallowed in
subqueries (including subqueries in the FROM clause, and SELECT
statements in unions other than the first SELECT.
(Bug#35020: http://bugs.mysql.com/35020)

* The undocumented, deprecated, and not useful SHOW COLUMN TYPES
statement has been removed.
(Bug#5299: http://bugs.mysql.com/5299)

* Several improvements were made to MySQL Backup (the BACKUP
DATABASE and RESTORE statements): + Drivers are now included for
storage engines that do not store any data or rely on other
storage engines for data storage: MERGE, FEDERATED, BLACKHOLE,
EXAMPLE. + The backup kernel better determines the dependency
ordering of objects to be backed up so that they can be restored
in the proper order. + Restored events and triggers are not
reactivated until the restore operation completes.

* BACKUP DATABASE now has a WITH COMPRESSION clause. This causes
the image file to be compressed, which reduces its size.
Compression also may result in improved backup time by reducing
writes to disk.

* The Maria Storage Engine is now available as standard.


■バグ修正：
* Incompatible Change: Access privileges for several statements
are more accurately checked: + CHECK TABLE requires some
privilege for the table. + CHECKSUM TABLE requires SELECT for
the table. + CREATE TABLE ... LIKE requires SELECT for the
source table and CREATE for the destination table. + SHOW
COLUMNS displays information only for those columns you have
some privilege for. + SHOW CREATE TABLE requires some privilege
for the table (previously required SELECT). + SHOW CREATE VIEW
requires SHOW VIEW and SELECT for the view. + SHOW INDEX
requires some privilege for any column. + SHOW OPEN TABLES
displays only tables for which you have some privilege on any
table column.
(Bug#27145: http://bugs.mysql.com/27145)

* Incompatible Change: Certain characters were sorted
incorrectly for the following collations: TILDE and GRAVE ACCENT
in big5_chinese_ci; LATIN SMALL LETTER J in cp866_general_ci;
TILDE in gb2312_chinese_ci; and TILDE in gbk_chinese_ci. As a
result of this fix, any indexes on columns that use these
collations and contain the affected characters must be rebuilt
when upgrading to 6.0.6 or higher. To do this, use ALTER TABLE
to drop and re-add the indexes, or mysqldump to dump the
affected tables and mysql to reload the dump file.
(Bug#25420: http://bugs.mysql.com/25420)

* Incompatible Change: An additional correction to the original
MySQL 6.0.4 fix was made to normalize directory names before
adding them to the list of directories. This prevents /etc/ and
/etc from being considered different, for example.
(Bug#20748: http://bugs.mysql.com/20748)
See also Bug#38180: http://bugs.mysql.com/38180

* Important Change: The server no longer issues warnings for
truncation of excess spaces for values inserted into CHAR
columns. This reverts a change in the previous release that
caused warnings to be issued.
(Bug#30059: http://bugs.mysql.com/30059)

* Partitioning: When one user was in the midst of a transaction
on a partitioned table, a second user performing an ALTER TABLE
on this table caused the server to hang.
(Bug#34604: http://bugs.mysql.com/34604)

* Partitioning: Inserts failed on partitioned tables containing
user-supplied values for an AUTO_INCREMENT column.
(Bug#33479: http://bugs.mysql.com/33479)

* Replication: CREATE PROCEDURE and CREATE FUNCTION statements
containing extended comments were not written to the binary log
correctly, causing parse errors on the slave.
(Bug#36570: http://bugs.mysql.com/36570)
See also Bug#32575: http://bugs.mysql.com/32575

* Replication: When flushing tables, there was a slight chance
that the flush occurred between the processing of one table map
event and the next. Since the tables were opened one by one,
subsequent locking of tables would cause the slave to crash.
This problem was observed when replicating NDBCLUSTER or InnoDB
tables, when executing multi-table updates, and when a trigger
or a stored routine performed an (additional) insert on a table
so that two tables were effectively being inserted into in the
same statement.
(Bug#36197: http://bugs.mysql.com/36197)

* Replication: CREATE VIEW statements containing extended
comments were not written to the binary log correctly, causing
parse errors on the slave. Now, all comments are stripped from
such statements before being written to the binary log.
(Bug#32575: http://bugs.mysql.com/32575)
See also Bug#36570: http://bugs.mysql.com/36570

* The Windows my-template.ini template file contained a
reference to the myisam_max_extra_sort_file_size system
variable, which no longer exists, causing the installed server
to fail upon startup.
(Bug#38371: http://bugs.mysql.com/38371)

* The fix for Bug#33812: http://bugs.mysql.com/33812 had the
side effect of causing the mysql client not to be able to read
some dump files produced with mysqldump. To address this, that
fix was reverted.
(Bug#38158: http://bugs.mysql.com/38158)

* Building MySQL with SSL and Falcon enabled would lead to a
build failure.
(Bug#37517: http://bugs.mysql.com/37517)

* The code for the ut_usectime() function in InnoDB did not
handle errors from the gettimeofday() system call. Now it
retries gettimeofday() several times and updates the value of
the Innodb_row_lock_time_max status variable only if
ut_usectime() was successful.
(Bug#36819: http://bugs.mysql.com/36819)

* If the length of a field was 3, internal InnoDB to integer
type conversion didn't work on big-endian machines in the
row_search_autoinc_column() function.
(Bug#36793: http://bugs.mysql.com/36793)

* For a view that referred to a MyISAM table, the contents of
the table could be empty after BACKUP DATABASE followed by
RESTORE.
(Bug#36782: http://bugs.mysql.com/36782)

* Data loss could be caused by attempts to read data from a
database being restored by a RESTORE operation.
(Bug#36778: http://bugs.mysql.com/36778)

* Data loss could be caused by activation of a trigger for a
MyISAM table being restored by a RESTORE operation.
(Bug#36749: http://bugs.mysql.com/36749)

* On Windows 64-bit systems, temporary variables of long types
were used to store ulong values, causing key cache
initialization to receive distorted parameters. The effect was
that setting key_buffer_size to values of 2GB or more caused
memory exhaustion to due allocation of too much memory.
(Bug#36705: http://bugs.mysql.com/36705)

* Multiple-table UPDATE statements that used a temporary table
could fail to update all qualifying rows or fail with a spurious
duplicate-key error.
(Bug#36676: http://bugs.mysql.com/36676)

* The online backup stream library failed to parse the backup
(Bug#36624: http://bugs.mysql.com/36624)

* SHOW STATUS took a lot of CPU time for calculating the value
of the Innodb_buffer_pool_pages_latched status variable. Now
this variable is calculated and included in the output of SHOW
STATUS only when the UNIV_DEBUG symbol is defined at server
build time.
(Bug#36600: http://bugs.mysql.com/36600)

* On 64-bit platforms, BACKUP DATABASE hung for backups of more
than 32KB.
(Bug#36586: http://bugs.mysql.com/36586)

* A REGEXP match could return incorrect rows when the previous
row matched the expression and used CONCAT() with an empty
string.
(Bug#36488: http://bugs.mysql.com/36488)

* mysqltest ignored the value of --tmpdir in one place.
(Bug#36465: http://bugs.mysql.com/36465)

* The ER_TRUNCATED_WRONG_VALUE warning condition was sometimes
raised as an error.
(Bug#36457: http://bugs.mysql.com/36457)

* ha_innodb.so was incorrectly installed in the lib/mysql
directory rather than in lib/mysql/plugin.
(Bug#36434: http://bugs.mysql.com/36434)

* The default drivers for BACKUP DATABASE and RESTORE now
support a cancel operation, which also allows better cleanup if
a driver error occurs.
(Bug#36323: http://bugs.mysql.com/36323)

* The server crashed while parsing large floating-point numbers
such as 1e37 or -1e15.
(Bug#36320: http://bugs.mysql.com/36320)

* When updating an existing instance (for example, from MySQL
5.0 to 5.1, or 5.1 to 6.0), the Instance Configuration Wizard
unnecessarily prompted for a root password when there was an
existing root password.
(Bug#36305: http://bugs.mysql.com/36305)

* For InnoDB tables, the DATA_FREE column of the
INFORMATION_SCHEMA.TABLES displayed free space in kilobytes
rather than bytes. Now it displays bytes.
(Bug#36278: http://bugs.mysql.com/36278)

* BACKUP DATABASE failed to back up views that depend on tables
in a different database.
(Bug#36265: http://bugs.mysql.com/36265)

* The project files created for Windows were missing the
GenError project dependency.
(Bug#36257: http://bugs.mysql.com/36257)

* The mysql client failed to recognize comment lines consisting
of -- followed by a newline.
(Bug#36244: http://bugs.mysql.com/36244)

* CREATE INDEX for InnoDB tables could under very rare
circumstances cause the server to crash..
(Bug#36169: http://bugs.mysql.com/36169)

* A read past the end of the string could occur while parsing
the value of the --innodb-data-file-path option.
(Bug#36149: http://bugs.mysql.com/36149)

* Conversion of a FLOAT ZEROFILL value to string could cause a
server crash if the value was NULL.
(Bug#36139: http://bugs.mysql.com/36139)

* The combination of semi-join and materialization both being
enabled could lead to assertion failure during subquery
processing.
(Bug#36137: http://bugs.mysql.com/36137)

* Range optimizer evaluation of IN subqueries to be handled with
the materialization strategy could lead to assertion failure.
(Bug#36133: http://bugs.mysql.com/36133)

* A server crash could occur during the cleanup phase of
subquery execution.
(Bug#36128: http://bugs.mysql.com/36128)

* On Windows, the installer attempted to use JScript to
determine whether the target data directory already existed. On
Windows Vista x64, this resulted in an error because the
installer was attempting to run the JScript in a 32-bit engine,
which wasn't registered on Vista. The installer no longer uses
JScript but instead relies on a native WiX command.
(Bug#36103: http://bugs.mysql.com/36103)

* mysqltest was performing escape processing for the
--replace_result command, which it should not have been.
(Bug#36041: http://bugs.mysql.com/36041)

* An error in calculation of the precision of zero-length items
(such as NULL) caused a server crash for queries that employed
temporary tables.
(Bug#36023: http://bugs.mysql.com/36023)

* For EXPLAIN EXTENDED, execution of an uncorrelated IN subquery
caused a crash if the subquery required a temporary table for
its execution.
(Bug#36011: http://bugs.mysql.com/36011)

* The MERGE storage engine did a table scan for SELECT COUNT(*)
statements when it could calculate the number of records from
the underlying tables.
(Bug#36006: http://bugs.mysql.com/36006)

* The server crashed inside NOT IN subqueries with an impossible
WHERE or HAVING clause, such as NOT IN (SELECT ... FROM t1, t2,
... WHERE 0).
(Bug#36005: http://bugs.mysql.com/36005)

* mysql_stmt_prepare() did not reset the list of messages (those
messages available via SHOW WARNINGS).
(Bug#36004: http://bugs.mysql.com/36004)

* The Event Scheduler was not designed to work under the
embedded server. It is now disabled for the embedded server, and
the event_scheduler system variable is not displayed.
(Bug#35997: http://bugs.mysql.com/35997)

* Grouping or ordering of long values in unindexed BLOB or TEXT
columns with the gbk or big5 character set crashed the server.
(Bug#35993: http://bugs.mysql.com/35993)

* SET GLOBAL debug='' resulted in a Valgrind warning in
DbugParse(), which was reading beyond the end of the control
string.
(Bug#35986: http://bugs.mysql.com/35986)

* If a SELECT table list contained at least one
INFORMATION_SCHEMA table, the required privileges for accessing
the other tables were reduced.
(Bug#35955: http://bugs.mysql.com/35955)

* Some syntactically invalid statements could cause the server
to return an error message containing garbage characters.
(Bug#35936: http://bugs.mysql.com/35936)

* The "prefer full scan on clustered primary key over full scan
of any secondary key" optimizer rule introduced by Bug#26447:
http://bugs.mysql.com/26447 caused a performance regression for
some queries, so it has been disabled.
(Bug#35850: http://bugs.mysql.com/35850)

* The server ignored any covering index used for ref access of a
table in a query with ORDER BY if this index was incompatible
with the ORDER BY list and there was another covering index
compatible with this list. As a result, suboptimal execution
plans were chosen for some queries that used an ORDER BY clause.
(Bug#35844: http://bugs.mysql.com/35844)

* mysql_upgrade did not properly update the mysql.event table.
(Bug#35824: http://bugs.mysql.com/35824)

* The current system time (as returned by NOW() or synonyms)
became constant after a RESTORE operation.
(Bug#35806: http://bugs.mysql.com/35806)

* Processing of an uncorrelated subquery using semi-join could
cause incorrect results or a server crash.
(Bug#35767: http://bugs.mysql.com/35767)

* An incorrect error and message was produced for attempts to
create a MyISAM table with an index (.MYI) filename that was
already in use by some other MyISAM table that was open at the
same time. For example, this might happen if you use the same
value of the INDEX DIRECTORY table option for tables belonging
to different databases.
(Bug#35733: http://bugs.mysql.com/35733)

* Enabling the read_only system variable while autocommit mode
was enabled caused SELECT statements for transactional storage
engines to fail.
(Bug#35732: http://bugs.mysql.com/35732)

* The range optimizer ignored conditions on inner tables in
semi-join IN subqueries, causing the the optimizer to miss good
query execution plans.
(Bug#35674: http://bugs.mysql.com/35674)

* An empty bit-string literal (b'') caused a server crash. Now
the value is parsed as an empty bit value (which is treated as
an empty string in string context or 0 in numeric context).
(Bug#35658: http://bugs.mysql.com/35658)

* For InnoDB tables, REPLACE statements used "traditional" style
locking, regardless of the setting of innodb_autoinc_lock_mode.
Now REPLACE works the same way as "simple inserts" instead of
using the old locking algorithm. (REPLACE statements are
treated in the same way as as INSERT statements.)
(Bug#35602: http://bugs.mysql.com/35602)

* Different invocations of CHECKSUM TABLE could return different
results for a table containing columns with spatial data types.
(Bug#35570: http://bugs.mysql.com/35570)

* A semi-join subquery in the ON clause in the absence of a
WHERE clause caused a server crash.
(Bug#35550: http://bugs.mysql.com/35550)

* InnoDB was not updating the Handler_delete or Handler_update
status variables.
(Bug#35537: http://bugs.mysql.com/35537)

* If the server crashed with an InnoDB error due to
unavailability of undo slots, errors could persist during
rollback when the server was restarted: There are two UNDO slot
caches (for INSERT and UPDATE). If all slots end up in one of
the slot caches, a request for a slot from the other slot cache
would fail. This can happen if the request is for an UPDATE slot
and all slots are in the INSERT slot cache, or vice versa.
(Bug#35352: http://bugs.mysql.com/35352)

* The combination of GROUP_CONCAT(), DISTINCT, and LEFT JOIN
could crash the server when the right table is empty.
(Bug#35298: http://bugs.mysql.com/35298)

* Accessing a MERGE table with an empty underlying table list
incorrectly resulted in a "wrong index" error message rather
than "end of file."
(Bug#35274: http://bugs.mysql.com/35274)

* BACKUP DATABASE caused a server crash upon encountering a
table row that has been marked for deletion but not removed.
(Bug#35249: http://bugs.mysql.com/35249)

* For InnoDB tables, ALTER TABLE DROP failed if the name of the
column to be dropped began with "foreign".
(Bug#35220: http://bugs.mysql.com/35220)

* The table pullout strategy was not reflected in EXPLAIN
EXTENDED output if not all of the subquery tables were pulled
out.
(Bug#35160: http://bugs.mysql.com/35160)

* Access-denied messages for INFORMATION_SCHEMA incorrectly
showed the name of the default database instead.
(Bug#35096: http://bugs.mysql.com/35096)

* Passing an invalid parameter to CHAR() in an ORDER BY clause
caused the server to hang.
(Bug#34949: http://bugs.mysql.com/34949)

* Some binaries produced stack corruption messages due to being
built with versions of bison older than 2.1. Builds are now
created using bison 2.3.
(Bug#34926: http://bugs.mysql.com/34926)

* Concurrent execution of FLUSH TABLES along with SHOW FUNCTION
STATUS or SHOW PROCEDURE STATUS could cause a server crash.
(Bug#34895: http://bugs.mysql.com/34895)

* The log_output system variable could be set to an illegal
value.
(Bug#34820: http://bugs.mysql.com/34820)

* A server crash or memory overrun could occur with a dependent
subquery and joins.
(Bug#34799: http://bugs.mysql.com/34799)

* InnoDB could crash if overflow occurred for an AUTO_INCREMENT
column.
(Bug#34335: http://bugs.mysql.com/34335)

* On Windows 64-bit builds, an apparent compiler bug caused
memory overruns for code in innobase/mem/*. Removed
optimizations so as not to trigger this problem.
(Bug#34297: http://bugs.mysql.com/34297)

* Several additional configuration scripts in the BUILD
directory now are included in source distributions. These may be
useful for users who wish to build MySQL from source. (See
Section 2.9.3, "Installing from the Development Source Tree,"
for information about what they do.)
(Bug#34291: http://bugs.mysql.com/34291)

* For InnoDB tables, loss of data resulted from performing
inserts concurrently with a RESTORE operation.
(Bug#34210: http://bugs.mysql.com/34210)

* A number of problems in new subquery optimization code meant
that MySQL could pick an incorrect query plan when using
InsideOut and/or FirstMatch subquery optimizations, which in
turn would cause wrong query results.
(Bug#33743: http://bugs.mysql.com/33743)

* TIMESTAMP columns were restored to the current date and time
(not their actual values) by a RESTORE operation.
(Bug#33573: http://bugs.mysql.com/33573)

* Use of 61 nested subqueries caused a server crash.
(Bug#33509: http://bugs.mysql.com/33509)

* For InnoDB tables, there was a race condition involving the
data dictionary and repartitioning.
(Bug#33349: http://bugs.mysql.com/33349)

* Executing a FLUSH PRIVILEGES statement after creating a
temporary table in the mysql database with the same name as one
of the MySQL system tables caused the server to crash. Note:
While it is possible to shadow a system table in this way, the
temporary table exists only for the current user and connection,
and does not effect any user privileges.
(Bug#33275: http://bugs.mysql.com/33275)

* Selecting from a view that referenced the same table in the
FROM clause and an IN clause caused a server crash.
(Bug#33245: http://bugs.mysql.com/33245)

* There was a race condition between the event scheduler and the
server shutdown thread.
(Bug#32771: http://bugs.mysql.com/32771)

* Assignment of relative pathnames to general_log_file or
slow_query_log_file did not always work.
(Bug#32748: http://bugs.mysql.com/32748)

* Deeply nested subqueries could cause stack overflow or a
server crash.
(Bug#32680: http://bugs.mysql.com/32680)

* Conversion of binary values to multi-byte character sets could
fail to left-pad values to the correct length. This could result
in a server crash.
(Bug#32394: http://bugs.mysql.com/32394)

* Killing a statement that invoked a stored function could
return an incorrect error message indicating table corruption
rather than that the statement had been interrupted.
(Bug#32140: http://bugs.mysql.com/32140)

* Occurrence of an error within a stored routine did not always
cause immediate statement termination.
(Bug#31881: http://bugs.mysql.com/31881)

* For DROP FUNCTION db_name.func_name (that is, when the
function name is qualified with the database name), the
statement should apply only to a stored function named func_name
in the given database. However, if a UDF with the same name
existed, the statement dropped the UDF instead.
(Bug#31767: http://bugs.mysql.com/31767)

* TRUNCATE TABLE for InnoDB tables returned a count showing too
many rows affected. Now the statement returns 0 for InnoDB
tables.
(Bug#29507: http://bugs.mysql.com/29507)

* InnoDB could return an incorrect rows-updated value for UPDATE
statements.
(Bug#29157: http://bugs.mysql.com/29157)

* The mysql.servers table was not created during installation on
Windows.
(Bug#28680: http://bugs.mysql.com/28680, Bug#32797:
http://bugs.mysql.com/32797)

* The jp test suite was not working.
(Bug#28563: http://bugs.mysql.com/28563)

* The internal init_time() library function was renamed to
my_init_time() to avoid conflicts with external libraries.
(Bug#26294: http://bugs.mysql.com/26294)

* In some cases, the parser interpreted the ; character as the
end of input and misinterpreted stored program definitions.
(Bug#26030: http://bugs.mysql.com/26030)

* Statements to create, alter, or drop a view were not waiting
for completion of statements that were using the view, which led
to incorrect sequences of statements in the binary log when
statement-based logging was enabled.
(Bug#25144: http://bugs.mysql.com/25144)

* The Questions status variable is intended as a count of
statements sent by clients to the server, but was also counting
statements executed within stored routines.
(Bug#24289: http://bugs.mysql.com/24289)

* InnoDB exhibited thread thrashing with more than 50 concurrent
connections under an update-intensive workload.
(Bug#22868: http://bugs.mysql.com/22868)

* DROP DATABASE did not drop orphaned FOREIGN KEY constraints.
(Bug#18942: http://bugs.mysql.com/18942)

* Delayed-insert threads were counted as connected but not as
created, incorrectly leading to a Threads_connected value
greater than the Threads_created value.
(Bug#17954: http://bugs.mysql.com/17954)

* The parser used signed rather than unsigned values in some
cases that caused legal lengths in column declarations to be
rejected.
(Bug#15776: http://bugs.mysql.com/15776)

* Stored procedure exception handlers were catching fatal errors
(such as out of memory errors), which could cause execution not
to stop to due a continue handler. Now fatal errors are not
caught by exception handlers and a fatal error is returned to
the client.
(Bug#15192: http://bugs.mysql.com/15192)

* On Windows, moving an InnoDB .ibd file and then symlinking to
it in the database directory using a .sym file caused a server
crash.
(Bug#11894: http://bugs.mysql.com/11894)

* If a connection was waiting for a GET_LOCK() lock or a SLEEP()
call, and the connection aborted, the server did not detect this
and thus did not close the connection. This caused a waste of
system resources allocated to dead connections. Now the server
checks such a connection every five seconds to see whether it
has been aborted. If so, the connection is killed (and any lock
request is aborted).
(Bug#10374: http://bugs.mysql.com/10374)