Dear MySQL users,
MySQL Community Server 5.0.51, a new version of the popular Open Source
Database Management System, has been released. The release is now
available in source form (only) from our download pages at
and mirror sites.
Note that not all mirror sites may be up to date at this point in time,
so if you can't find this version on some mirror, please try again later
or choose another download site.
We welcome and appreciate your feedback, bug reports, bug fixes,
The following section lists the changes from version to version in the
MySQL source code as compared to the last released version of MySQL
Community Server, the MySQL Community Server 5.0.45 release.
It can also be viewed online at
This is a bugfix release for the current production release
family. It replaces MySQL 5.0.45.
* Using RENAME TABLE against a table with explicit DATA
DIRECTORY and INDEX DIRECTORY options can be used to
overwrite system table information by replacing the file
to which the symlink points.
MySQL will now return an error when the file to which the
symlink points already exists.
(Bug#32111: http://bugs.mysql.com/32111, CVE-2007-5969
Functionality added or changed:
* MySQL Cluster: Mapping of NDB error codes to MySQL
storage engine error codes has been improved.
* MySQL Cluster: auto_increment_increment and
auto_increment_offset are now supported for NDB tables.
* MySQL Cluster: The output from the cluster management
client showing the progress of data node starts has been
improved. (Bug#23354: http://bugs.mysql.com/23354)
* Server parser performance was improved for expression
parsing by lowering the number of state transitions and
* Server parser performance was improved for boolean
expressions. (Bug#30237: http://bugs.mysql.com/30237)
* If a MyISAM table is created with no DATA DIRECTORY
option, the .MYD file is created in the database
directory. By default, if MyISAM finds an existing .MYD
file in this case, it overwrites it. The same applies to
.MYI files for tables created with no INDEX DIRECTORY
option. To suppress this behavior, start the server with
the new --keep_files_on_create option, in which case
MyISAM will not overwrite existing files and returns an
error instead. (Bug#29325: http://bugs.mysql.com/29325)
* If a MERGE table cannot be opened or used because of a
problem with an underlying table, CHECK TABLE now
displays information about which table caused the
problem. (Bug#26976: http://bugs.mysql.com/26976)
* The SQL_MODE, FOREIGN_KEY_CHECKS, UNIQUE_CHECKS,
character set/collations, and SQL_AUTO_IS_NULL sesstion
variables are written to the binary log and honoured
during replication. See Section 5.10.3, "The Binary Log."
* The EXAMPLE storage engine is now enabled by default.
* Incompatible Change: The parser accepted statements that
contained /* ... */ that were not properly closed with
*/, such as SELECT 1 /* + 2. Statements that contain
unclosed /*-comments now are rejected with a syntax
This fix has the potential to cause incompatibilities.
Because of Bug#26302: http://bugs.mysql.com/26302, which
caused the trailing */ to be truncated from comments in
views, stored routines, triggers, and events, it is
possible that objects of those types may have been stored
with definitions that now will be rejected as
syntactically invalid. Such objects should be dropped and
re-created so that their definitions do not contain
truncated comments. If a stored object definition
contains only a single statement (does not use a BEGIN
... END block) and contains a comment within the
statement, the comment should be moved to follow the
statement or the object should be rewritten to use a
BEGIN ... END block. For example, this statement:
CREATE PROCEDURE p() SELECT 1 /* my comment */ ;
can be rewritten in either of these ways:
CREATE PROCEDURE p() SELECT 1; /* my comment */
CREATE PROCEDURE p() BEGIN SELECT 1 /* my comment */ ; END;
* MySQL Cluster: Packaging: Some commercial MySQL Cluster
RPM packages included support for the InnoDB storage
engine. (InnoDB is not part of the standard commercial
MySQL Cluster offering.)
* Multiple-table DELETE statements could delete rows from
the wrong table. (Bug#30234: http://bugs.mysql.com/30234)
* MySQL Cluster: Attempting to restore a backup made on a
cluster host using one endian to a machine using the
other endian could cause the cluster to fail.
* MySQL Cluster: When restarting a data node, queries could
hang during that node's start phase 5, and continue only
after the node had entered phase 6.
* MySQL Cluster: Replica redo logs were inconsistently
handled during a system restart.
* MySQL Cluster: Reads on BLOB columns were not locked when
they needed to be to guarantee consistency.
See also Bug#31482: http://bugs.mysql.com/31482
* MySQL Cluster: A query using joins between several large
tables and requiring unique index lookups failed to
complete, eventually returning Uknown Error after a very
long period of time. This occurred due to inadequate
handling of instances where the Transaction Coordinator
ran out of TransactionBufferMemory, when the cluster
should have returned NDB error code 4012 (Request ndbd
time-out). (Bug#28804: http://bugs.mysql.com/28804)
* MySQL Cluster: The description of the --print option
provided in the output from ndb_restore --help was
incorrect. (Bug#27683: http://bugs.mysql.com/27683)
* MySQL Cluster: The management client's response to START
BACKUP WAIT COMPLETED did not include the backup ID.
* MySQL Cluster: An invalid subselect on an NDB table could
cause mysqld to crash.
* MySQL Cluster: An attempt to perform a SELECT ... FROM
INFORMATION_SCHEMA.TABLES whose result included
information about NDB tables for which the user had no
privileges crashed the MySQL Server on which the query
was performed. (Bug#26793: http://bugs.mysql.com/26793)
* MySQL Cluster: Warnings and errors generated by
ndb_config --config-file=file were sent to stdout, rather
than to stderr. (Bug#25941: http://bugs.mysql.com/25941)
* MySQL Cluster: Large file support did not work in AIX
server binaries. (Bug#10776: http://bugs.mysql.com/10776)
* When a TIMESTAMP with a non-zero time part was converted
to a DATE value, no warning was generated. This caused
index lookups to assume that this is a valid conversion
and was returning rows that match a comparison between a
TIMESTAMP value and a DATE keypart. Now a warning is
generated so that TIMESTAMP with a non-zero time part
will not match DATE values.
* A server crash could occur when a non-DETERMINISTIC
stored function was used in a GROUP BY clause.
* For an InnoDB table if a SELECT was ordered by the
primary key and also had a WHERE field = value clause on
a different field that was indexed, a DESC order
instruction would be ignored.
* A failed HANDLER ... READ operation could leave the table
in a locked state.
* The optimization that uses a unique index to remove GROUP
BY did not ensure that the index was actually used, thus
violating the ORDER BY that is implied by GROUP BY.
* SHOW STATUS LIKE 'Ssl_cipher_list' from a MySQL client
connected via SSL returned an empty string rather than a
list of available ciphers.
* Memory corruption occurred for some queries with a
top-level OR operation in the WHERE condition if they
contained equality predicates and other sargable
predicates in disjunctive parts of the condition.
* Issuing a DELETE statement having both an ORDER BY clause
and a LIMIT clause could cause mysqld to crash.
* The Last_query_cost status variable value can be computed
accurately only for simple "flat" queries, not complex
queries such as those with subqueries or UNION. However,
the value was not consistently being set to 0 for complex
queries. (Bug#30377: http://bugs.mysql.com/30377)
* Queries that had a GROUP BY clause and selected
COUNT(DISTINCT bit_column) returned incorrect results.
* The server created temporary tables for filesort
operations in the working directory, not in the directory
specified by the tmpdir system variable.
* The query cache does not support retrieval of statements
for which column level access control applies, but the
server was still caching such statements, thus wasting
memory. (Bug#30269: http://bugs.mysql.com/30269)
* Using DISTINCT or GROUP BY on a BIT column in a SELECT
statement caused the column to be cast internally as an
integer, with incorrect results being returned from the
query. (Bug#30245: http://bugs.mysql.com/30245)
* GROUP BY on BIT columns produced incorrect results.
* Using KILL QUERY or KILL CONNECTION to kill a SELECT
statement caused a server crash if the query cache was
enabled. (Bug#30201: http://bugs.mysql.com/30201)
* Prepared statements containing CONNECTION_ID() could
be written improperly to the binary log.
* When a thread executing a DROP TABLE statement was
killed, the table name locks that had been acquired were
not released. (Bug#30193: http://bugs.mysql.com/30193)
* Short-format mysql commands embedded within /*! ... */
comments were parsed incorrectly by mysql, which
discarded the rest of the comment including the
terminating */ characters. The result was a malformed
(unclosed) comment. Now mysql does not discard the */
characters. (Bug#30164: http://bugs.mysql.com/30164)
* When mysqldump wrote DROP DATABASE statements within
version-specific comments, it included the terminating
semicolon in the wrong place, causing following
statements to fail when the dump file was reloaded.
* Use of local variables with non-ASCII names in stored
procedures crashed the server.
* On Windows, client libraries lacked symbols required for
linking. (Bug#30118: http://bugs.mysql.com/30118)
* --myisam-recover='' (empty option value) did not disable
MyISAM recovery. (Bug#30088: http://bugs.mysql.com/30088)
* Statements within stored procedures ignored the value of
the low_priority_updates system variable.
See also Bug#26162: http://bugs.mysql.com/26162
* For MyISAM tables on Windows, INSERT, DELETE, or UPDATE
followed by ALTER TABLE within LOCK TABLES could cause
* With auto-reconnect enabled, row fetching for a prepared
statement could crash after reconnect occurred because
loss of the statement handler was not accounted for.
* LOCK TABLES did not pre-lock tables used in triggers of
the locked tables. Unexpected locking behavior and
statement failures similar to failed: 1100: Table 'xx'
was not locked with LOCK TABLES could result.
* INSERT ... VALUES(CONNECTION_ID(), ...) statements were
written to the binary log in such a way that they could
not be properly restored.
* Adding DISTINCT could cause incorrect rows to appear in a
query result. (Bug#29911: http://bugs.mysql.com/29911)
* Using the DATE() function in a WHERE clause did not
return any records after encountering NULL. However,
using TRIM or CAST produced the correct results.
* Very long prepared statements in stored procedures could
cause a server crash.
* If query execution involved a temporary table,
GROUP_CONCAT() could return a result with an incorrect
character set. (Bug#29850: http://bugs.mysql.com/29850)
* If one thread was performing concurrent inserts, other
threads reading from the same table using equality key
searches could see the index values for new rows before
the data values had been written, leading to reports of
* Repeatedly accessing a view in a stored procedure (for
example, in a loop) caused a small amount of memory to be
allocated per access. Although this memory is deallocated
on disconnect, it could be a problem for a long running
stored procedures that make repeated access of views.
* mysqldump produced output that incorrectly discarded the
NO_AUTO_VALUE_ON_ZERO value of the SQL_MODE variable
after dumping triggers.
* An assertion failure occurred within yaSSL for very long
keys. (Bug#29784: http://bugs.mysql.com/29784)
* For MEMORY tables, the index_merge union access method
could return incorrect results.
* Comparison of TIME values using the BETWEEN operator
led to string comparison, producing incorrect results in
some cases. Now the values are compared as integers.
* The thread ID was not reset properly after execution of
mysql_change_user(), which could cause replication
failure when replicating temporary tables.
* For a table with a DATE column date_col such that
selecting rows with WHERE date_col = 'date_val 00:00:00'
yielded a non-empty result, adding GROUP BY date_col
caused the result to be empty.
* In some cases, INSERT INTO ... SELECT ... GROUP BY could
insert rows even if the SELECT by itself produced an
empty result. (Bug#29717: http://bugs.mysql.com/29717)
* For the embedded server, the mysql_stmt_store_result()
C API function caused a memory leak for empty result
sets. (Bug#29687: http://bugs.mysql.com/29687)
* EXPLAIN produced Impossible where for statements of the
form SELECT ... FROM t WHERE c=0, where c was an ENUM
column defined as a primary key.
* On Windows, ALTER TABLE hung if records were locked in
share mode by a long-running transaction.
* A left join between two views could produce incorrect
results. (Bug#29604: http://bugs.mysql.com/29604)
* Certain statements with unions, subqueries, and joins
could result in huge memory consumption.
* Clients using SSL could hang the server.
* A slave running with --log-slave-updates would fail to
write INSERT DELAY IGNORE statements to its binary log,
resulting in different binary log contents on the master
and slave. (Bug#29571: http://bugs.mysql.com/29571)
* An incorrect result was returned when comparing string
values that were converted to TIME values with CAST().
* gcov coverage-testing information was not written if the
server crashed. (Bug#29543: http://bugs.mysql.com/29543)
* Operations that used the time zone replicated the time
zone only for successful operations, but did not
replicate the time zone for errors that need to know it.
* Conversion of ASCII DEL (0x7F) to Unicode incorrectly
resulted in QUESTION MARK (0x3F) rather than DEL.
* A field packet with NULL fields caused a libmysqlclient
crash. (Bug#29494: http://bugs.mysql.com/29494)
* When using a combination of HANDLER... READ and DELETE on
a table, MySQL continued to open new copies of the table
every time, leading to an exhaustion of file descriptors.
This regression was introduced by
* On Windows, the mysql client died if the user entered a
statement and Return after entering Control-C.
* Failure to consider collation when comparing space
characters could lead to incorrect index entry order,
making it impossible to find some index values.
* Corrupt data resulted from use of SELECT ... INTO OUTFILE
'file_name' FIELDS ENCLOSED BY 'c', where c is a digit or
minus sign, followed by LOAD DATA INFILE 'file_name'
FIELDS ENCLOSED BY 'c'.
* Killing an INSERT DELAYED thread caused a server crash.
* Use of SHOW BINLOG EVENTS for a non-existent log file
followed by PURGE MASTER LOGS caused a server crash.
* Assertion failure could occur for grouping queries that
employed DECIMAL user variables with assignments to them.
* For CAST(expr AS DECIMAL(M,D)), the limits of 65 and
30 on the precision (M) and scale (D) were not enforced.
* If a view used a function in its SELECT statement, the
columns from the view were not inserted into the
* Results for a select query that aliases the column names
against a view could duplicate one column while omitting
another. This bug could occur for a query over a
multiple-table view that includes an ORDER BY clause in
its definition. (Bug#29392: http://bugs.mysql.com/29392)
* mysqldump created a stray file when a given a too-long
* The special "zero" ENUM value was coerced to the normal
empty string ENUM value during a column-to-column copy.
This affected CREATE ... SELECT statements and SELECT
statements with aggregate functions on ENUM columns in
the GROUP BY clause.
* Optimization of queries with DETERMINISTIC stored
functions in the WHERE clause was ineffective: A
sequential scan was always used.
* MyISAM corruption could occur with the cp932_japanese_ci
collation for the cp932 character set due to incorrect
comparison for trailing space.
* The mysql_list_fields() C API function incorrectly
set MYSQL_FIELD::decimals for some view columns.
* FULLTEXT indexes could be corrupted by certain gbk
characters. (Bug#29299: http://bugs.mysql.com/29299)
* SELECT ... INTO OUTFILE followed by LOAD DATA could
result in garbled characters when the FIELDS ENCLOSED BY
clause named a delimiter of '0', 'b', 'n', 'r', 't', 'N',
or 'Z' due to an interaction of character encoding and
doubling for data values containing the enclosed-by
character. (Bug#29294: http://bugs.mysql.com/29294)
* Sort order of the collation wasn't used when comparing
trailing spaces. This could lead to incorrect comparison
results, incorrectly created indexes, or incorrect result
set order for queries that include an ORDER BY clause.
* If an ENUM column contained '' as one of its members
(represented with numeric value greater than 0), and the
column contained error values (represented as 0 and
displayed as ''), using ALTER TABLE to modify the column
definition caused the 0 values to be given the numeric
value of the non-zero '' member.
* Calling mysql_options() after
mysql_real_connect() could cause clients to crash.
* CHECK TABLE for ARCHIVE tables could falsely report table
corruption or cause a server crash.
* Mixing binary and utf8 columns in a union caused field
lengths to be calculated incorrectly, resulting in
truncation. (Bug#29205: http://bugs.mysql.com/29205)
* AsText() could fail with a buffer overrun.
* InnoDB refused to start on some versions of FreeBSD with
LinuxThreads. This is fixed by enabling file locking on
FreeBSD. (Bug#29155: http://bugs.mysql.com/29155)
* LOCK TABLES was not atomic when more than one InnoDB
tables were locked.
* INSERT DELAYED statements on a master server are
replicated as non-DELAYED inserts on slaves (which is
normal, to preserve serialization), but the inserts on
the slave did not use concurrent inserts. Now INSERT
DELAYED on a slave is converted to a concurrent insert
when possible, and to a normal insert otherwise.
* A network structure was initialized incorrectly, leading
to embedded server crashes.
* An assertion failure occurred if a query contained a
conjunctive predicate of the form view_column = constant
in the WHERE clause and the GROUP BY clause contained a
reference to a different view column. The fix also
enables application of an optimization that was being
skipped if a query contained a conjunctive predicate of
the form view_column = constant in the WHERE clause and
the GROUP BY clause contained a reference to the same
view column. (Bug#29104: http://bugs.mysql.com/29104)
* A maximum of 4TB InnoDB free space was reported by SHOW
TABLE STATUS, which is incorrect on systems with more
than 4TB space. (Bug#29097: http://bugs.mysql.com/29097)
* If an INSERT INTO ... SELECT statement inserted into the
same table that the SELECT retrieved from, and the SELECT
included ORDER BY and LIMIT clauses, different data was
inserted than the data produced by the SELECT executed by
itself. (Bug#29095: http://bugs.mysql.com/29095)
* Queries that performed a lookup into a BINARY index
containing key values ending with spaces caused an
assertion failure for debug builds and incorrect results
for non-debug builds.
* The semantics of BIGINT depended on platform-specific
characteristics. (Bug#29079: http://bugs.mysql.com/29079)
* A byte-order issue in writing a spatial index to disk
caused bad index files on some systems.
* If one of the queries in a UNION used the SQL_CACHE
option and another query in the UNION contained a
nondeterministic function, the result was still cached.
For example, this query was incorrectly cached:
SELECT NOW() FROM t1 UNION SELECT SQL_CACHE 1 FROM t1;
* Creation of a legal stored procedure could fail if no
default database had been selected.
* DROP USER statements that named multiple users, only some
of which could be dropped, were replicated incorrectly.
* REPLACE, INSERT IGNORE, and UPDATE IGNORE did not work
for FEDERATED tables.
* Inserting into InnoDB tables and executing RESET MASTER
in multiple threads cause assertion failure in debug
server binaries. (Bug#28983: http://bugs.mysql.com/28983)
* For a ucs2 column, GROUP_CONCAT() did not convert
separators to the result character set before inserting
them, producing a result containing a mixture of two
different character sets.
* Queries using UDFs or stored functions were cached.
* For a join with GROUP BY and/or ORDER BY and a view
reference in the FROM list, the query metadata
erroneously showed empty table aliases and database names
for the view columns.
* Coercion of ASCII values to character sets that are a
superset of ASCII sometimes was not done, resulting in
illegal mix of collations errors. These cases now are
resolved using repertoire, a new string expression
attribute (see Section 9.1.6, "String Repertoire").
* Non-utf8 characters could get mangled when stored in CSV
tables. (Bug#28862: http://bugs.mysql.com/28862)
* ALTER VIEW is not supported as a prepared statement but
was not being rejected. ALTER VIEW is now prohibited as a
prepared statement or when called within stored routines.
* In strict SQL mode, errors silently stopped the SQL
thread even for errors named using the
* Fast ALTER TABLE (that works without rebuilding the
table) acquired duplicate locks in the storage engine. In
MyISAM, if ALTER TABLE was issued under LOCK TABLE, it
caused all data inserted after LOCK TABLE to disappear.
* Killing an SSL connection on platforms where MySQL is
compiled with -DSIGNAL_WITH_VIO_CLOSE (Windows, Mac OS X,
and some others) could crash the server.
* Runtime changes to the log_queries_not_using_indexes
system variable were ignored.
* Tables using the InnoDB storage engine incremented
AUTO_INCREMENT values incorrectly with ON DUPLICATE KEY
UPDATE. (Bug#28781: http://bugs.mysql.com/28781)
* Selecting a column not present in the selected-from table
caused an extra error to be produced by SHOW ERRORS.
* For a statement of the form CREATE t1 SELECT
integer_constant , the server created the column using
the DECIMAL data type for large negative values that are
within the range of BIGINT.
* For InnoDB tables, MySQL unnecessarily sorted records in
certain cases when the records were retrieved by InnoDB
in the proper order already.
* A SELECT in one connection could be blocked by INSERT ...
ON DUPLICATE KEY UPDATE in another connection even when
low_priority_updates is set.
* mysql_install_db could fail to find script files that it
needs. (Bug#28585: http://bugs.mysql.com/28585)
* When one thread attempts to lock two (or more) tables and
another thread executes a statement that aborts these
locks (such as REPAIR TABLE, OPTIMIZE TABLE, or CHECK
TABLE), the thread might get a table object with an
incorrect lock type in the table cache. The result is
table corruption or a server crash.
* mysql_upgrade could run binaries dynamically linked
against incorrect versions of shared libraries.
* If a stored procedure was created and invoked prior to
selecting a default database with USE, a No database
selected error occurred.
* On Mac OS X, shared-library installation pathnames were
incorrect. (Bug#28544: http://bugs.mysql.com/28544)
* Using the --skip-add-drop-table option with mysqldump
generated incorrect SQL if the database included any
views. The recreation of views requires the creation and
removal of temporary tables. This option suppressed the
removal of those temporary tables. The same applied to
--compact since this option also invokes
* mysqlbinlog --hexdump generated incorrect output due to
omission of the " # " comment character for some comment
lines. (Bug#28293: http://bugs.mysql.com/28293)
* The IS_UPDATABLE column in the INFORMATION_SCHEMA.VIEWS
table was not always set correctly.
* A race condition in the interaction between MyISAM and
the query cache code caused the query cache not to
invalidate itself for concurrently inserted data.
* Indexing column prefixes in InnoDB tables could cause
* Index creation could fail due to truncation of key values
to the maximum key length rather than to a mulitiple of
the maximum character length.
* The LOCATE() function returned NULL if any of its
arguments evaluated to NULL. Likewise, the predicate,
LOCATE(str,NULL) IS NULL, erroneously evaluated to
FALSE. (Bug#27932: http://bugs.mysql.com/27932)
* SHOW COLUMNS returned NULL instead of the empty string
for the Default value of columns that had no default
specified. (Bug#27747: http://bugs.mysql.com/27747)
* The modification of a table by a partially completed
multi-column update was not recorded in the binlog,
rather than being marked by an event and a corresponding
error code. (Bug#27716: http://bugs.mysql.com/27716)
* With recent versions of DBD::mysql, mysqlhotcopy
generated table names that were doubly qualified with the
database name. (Bug#27694: http://bugs.mysql.com/27694)
* The anonymous accounts were not being created during
* Some SHOW statements and INFORMATION_SCHEMA queries could
expose information not allowed by the user's access
privileges. (Bug#27629: http://bugs.mysql.com/27629)
* A stack overrun could occur when storing DATETIME values
using repeated prepared statements.
* Dropping a user-defined function could cause a server
crash if the function was still in use by another thread.
* Some character mappings in the ascii.xml file were
incorrect. (Bug#27562: http://bugs.mysql.com/27562)
* The parser rules for the SHOW PROFILE statement were
revised to work with older versions of bison.
* An error that happened inside INSERT, UPDATE, or DELETE
statements performed from within a stored function or
trigger could cause inconsistency between master and
slave servers. (Bug#27417: http://bugs.mysql.com/27417)
* Fixed a case of unsafe aliasing in the source that caused
a client library crash when compiled with gcc 4 at high
* A SELECT with more than 31 nested dependent subqueries
returned an incorrect result.
* Index-based range reads could fail for comparisons that
involved contraction characters (such as ch in Czech or
ll in Spanish). (Bug#27345: http://bugs.mysql.com/27345)
* Aggregations in subqueries that refer to outer query
columns were not always correctly referenced to the
proper outer query.
* INSERT INTO ... SELECT caused a crash if
innodb_locks_unsafe_for_binlog was enabled.
* Error returns from the time() system call were ignored.
* Phantom reads could occur under InnoDB serializable
isolation level. (Bug#27197: http://bugs.mysql.com/27197)
* The SUBSTRING() function returned the entire string
instead of an empty string when it was called from a
stored procedure and when the length parameter was
specified by a variable with the value " 0 ".
* ALTER TABLE ... ENABLE KEYS could cause mysqld to crash
when executed on a table containing on a MyISAM table
containing billions of rows.
* FEDERATED tables had an artificially low maximum of key
length. (Bug#26909: http://bugs.mysql.com/26909)
* Binary content 0x00 in a BLOB column sometimes became
0x5C 0x00 following a dump and reload, which could cause
problems with data using multi-byte character sets such
as GBK (Chinese). This was due to a problem with SELECT
INTO OUTFILE whereby LOAD DATA later incorrectly
interpreted 0x5C as the second byte of a multi-byte
sequence rather than as the SOLIDUS ("\") character, used
by MySQL as the escape character.
* Index creation could corrupt the table definition in the
.frm file: 1) A table with the maximum number of key
segments and maximum length key name would have a
corrupted .frm file, due to incorrect calculation of the
total key length. 2) MyISAM would reject a table with the
maximum number of keys and the maximum number of key
segments in all keys. (It would allow one less than this
total maximum.) Now MyISAM accepts a table defined with
the maximum. (Bug#26642: http://bugs.mysql.com/26642)
* After the first read of a TEMPORARY table, CHECK TABLE
could report the table as being corrupt.
* If an operation had an InnoDB table, and two triggers,
AFTER UPDATE and AFTER INSERT, competing for different
resources (such as two distinct MyISAM tables), the
triggers were unable to execute concurrently. In
addition, INSERT and UPDATE statements for the InnoDB
table were unable to run concurrently.
* ALTER DATABASE did not require at least one option.
* Using HANDLER to open a table having a storage engine not
supported by HANDLER properly returned an error, but also
improperly prevented the table from being dropped by
* The index merge union access algorithm could produce
incorrect results with InnoDB tables. The problem could
also occur for queries that used DISTINCT.
* When using a FEDERATED table, the value of
last_insert_id() would not correctly update the C API
interface, which would affect the autogenerated ID
returned both through the C API and the MySQL protocol,
affecting Connectors that used the protocol and/or C API.
* The server was blocked from opening other tables while
the FEDERATED engine was attempting to open a remote
table. Now the server does not check the correctness of a
FEDERATED table at CREATE TABLE time, but waits until the
table actually is accessed.
* Under ActiveState Perl, mysql-test-run.pl could kill
itself when attempting to kill other processes.
* Several InnoDB assertion failures were corrected.
* A query with DISTINCT in the select list to which the
loose-scan optimization for grouping queries was applied
returned an incorrect result set when the query was used
with the SQL_BIG_RESULT option.
* For a multiple-row insert into a FEDERATED table that
refers to a remote transactional table, if the insert
failed for a row due to constraint failure, the remote
table would contain a partial commit (the rows preceding
the failed one) instead of rolling back the statement
completely. This occurred because the rows were treated
as individual inserts.
Now FEDERATED performs bulk-insert handling such that
multiple rows are sent to the remote table in a batch.
This provides a performance improvement and enables the
remote table to perform statement rollback properly
should an error occur. This capability has the following
+ The size of the insert cannot exceed the maximum
packet size between servers. If the insert exceeds
this size, it is broken into multiple packets and
the rollback problem can occur.
+ Bulk-insert handling does not occur for INSERT ...
ON DUPLICATE KEY UPDATE.
* The FEDERATED storage engine failed silently for INSERT
... ON DUPLICATE KEY UPDATE if a duplicate key violation
occurred. FEDERATED does not support ON DUPLICATE KEY
UPDATE, so now it correctly returns an ER_DUP_KEY error
if a duplicate key violation occurs.
* For InnoDB tables, CREATE TABLE a AS SELECT * FROM A
would fail. (Bug#25164: http://bugs.mysql.com/25164)
* In a stored function or trigger, when InnoDB detected
deadlock, it attempted rollback and displayed an
incorrect error message (Explicit or implicit commit is
not allowed in stored function or trigger). Now InnoDB
returns an error under these conditions and does not
attempt rollback. Rollback is handled outside of InnoDB
above the function/trigger level.
* A too-long shared-memory-base-name value could cause a
buffer overflow and crash the server or clients.
* Dropping a temporary InnoDB table that had been locked
with LOCK TABLES caused a server crash.
* On Windows, executables did not include Vista manifests.
* Slave servers could incorrectly interpret an
out-of-memory error from the master and reconnect using
the wrong binary log position.
* If MySQL/InnoDB crashed very quickly after starting up,
it would not force a checkpoint. In this case, InnoDB
would skip crash recovery at next startup, and the
database would become corrupt. Fix: If the redo log scan
at InnoDB startup goes past the last checkpoint, force
crash recovery. (Bug#23710: http://bugs.mysql.com/23710)
* The server deducted some bytes from the
key_cache_block_size option value and reduced it to the
next lower 512 byte boundary. The resulting block size
was not a power of two. Setting the key_cache_block_size
system variable to a value that is not a power of two
resulted in MyISAM table corruption.
* SHOW INNODB STATUS caused an assertion failure under high
load. (Bug#22819: http://bugs.mysql.com/22819)
* SHOW BINLOG EVENTS displayed incorrect values of
End_log_pos for events associated with transactional
storage engines. (Bug#22540: http://bugs.mysql.com/22540)
* A statement of the form CREATE TABLE IF NOT EXISTS t1
SELECT f1() AS i failed with a deadlock error if the
stored function f1() referred to a table with the same
name as the to-be-created table. Now it correctly
produces a message that the table already exists.
* Read lock requests that were blocked by a pending write
lock request were not allowed to proceed if the statement
requesting the write lock was killed.
* Under heavy load with a large query cache, invalidating
part of the cache could cause the server to freeze (that
is, to be unable to service other operations until the
invalidation was complete).
* mysql-stress-test.pl and mysqld_multi.server.sh were
missing from some binary distributions.
* On Windows, the server used 10MB of memory for each
connection thread, resulting in memory exhaustion. Now
each thread uses 1MB.
* Worked around an icc problem with an incorrect machine
instruction being generated in the context of software
pre-fetching after a subroutine got in-lined. (Upgrading
to icc 10.0.026 makes the workaround unnecessary.)
* InnoDB produced an unnecessary (and harmless) warning:
InnoDB: Error: trying to declare trx to enter InnoDB, but
InnoDB: it already is declared.
* Under ActiveState Perl, mysql-test-run.pl would not run.
* The server crashed when the size of an ARCHIVE table grew
larger than 2GB. (Bug#15787: http://bugs.mysql.com/15787)
* SQL_BIG_RESULT had no effect for CREATE TABLE ... SELECT
SQL_BIG_RESULT ... statements.
* On 64-bit Windows systems, the Config Wizard failed to
complete the setup because 64-bit Windows does not
resolve dynamic linking of the 64-bit libmysql.dll to a
32-bit application like the Config Wizard.
* mysql_setpermission tried to grant global-only privileges
at the database level.
* Parameters of type DATETIME or DATE in stored procedures
were silently converted to VARBINARY.
* For the general query log, logging of prepared statements
executed via the C API differed from logging of prepared
statements performed with PREPARE and EXECUTE. Logging
for the latter was missing the Prepare and Execute lines.
* The server returned data from SHOW CREATE TABLE statement
or a SELECT statement on an INFORMATION_SCHEMA table
using the binary character set.
* Backup software can cause ERROR_SHARING_VIOLATION or
ERROR_LOCK_VIOLATION conditions during file operations.
InnoDB now retries forever until the condition goes away.
* Bulk-insert handling does not occur for INSERT ... ON
DUPLICATE KEY UPDATE.
* The size of the insert cannot exceed the maximum packet
size between servers. If the insert exceeds this size, it
is broken into multiple packets and the rollback problem
Joerg Bruehe, Senior Production Engineer
MySQL AB, www.mysql.com
|• MySQL 5.0.51 has been released||Joerg Bruehe||6 Dec|