This is a new Beta development release, fixing recently discovered bugs.
This Beta release, as any other pre-production release, should not be installed on production level systems or systems with critical data. It is good practice to back up your data before installing any new version of software. Although MySQL has worked very hard to ensure a high level of quality, protect your data by making a backup as you would for any software beta release. Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
Subsequent to release, it was discovered that on some platforms, mysql_install_db could fail to find its message file, resulting in error messages of the following form:
shell> mysql_install_db Installing MySQL system tables... 070830 9:33:24 [ERROR] Can't find messagefile '
path/share/english/errmsg.sys' 070830 9:33:24 [ERROR] Aborting
To deal with this problem, specify a
--language option to specify the
proper path name to the language file directory. For example:
shell> mysql_install_db --language=/path/to/share/english/
This problem is corrected in MySQL 5.1.22.
This section documents all changes and bug fixes that have been applied since the last official MySQL release. If you would like to receive more fine-grained and personalized update alerts about fixes that are relevant to the version and features you use, please consider subscribing to MySQL Enterprise (a commercial MySQL offering). For more details, please see http://www.mysql.com/products/enterprise.
Functionality added or changed:
In MySQL 5.1.6, when log tables were implemented, the default
log destination for the general query and slow query log was
TABLE. This default has been changed to
FILE, which is compatible with MySQL 5.0, but
incompatible with earlier releases of MySQL 5.1 from 5.1.6 to
5.1.20. If you are upgrading from MySQL 5.0 to 5.1.21 or higher,
no logging option changes should be necessary. However, if you
are upgrading from 5.1.6 through 5.1.20 to 5.1.21 or higher and
TABLE logging, use the
explicitly to preserve your server's table-logging behavior.
A further fix for this issue was made in MySQL 5.1.23. (Bug#29993)
variable (which has been deprecated since MySQL 5.0.24) has been
removed and should no longer be used.
Incompatible Change: On Windows only, the mysqld-nt has been removed from this release and all future releases. The mysqld server now includes named-pipe support as standard, and you do not have to use the mysqld-nt version to enable named-pipe support.
The default mysqld_safe logging behavior now
is compatible with the default behavior of writing an error log
file for releases prior to 5.1.20.
The SQL thread on a slave now is always allowed to enter
InnoDB even if this would exceed the limit
imposed by the
system variable. In cases of high load on the slave server (when
reached), this change helps the slave stay more up to date with
the master; in the previous behavior, the SQL thread was
competing for resources with all client threads active on the
Replication: Replication between master and slaves now supports different column numbers within a table on both master and slave. The rules for replication where the table definitions are different has also changed. This supercedes the functionality for replication from the master table to a slave table with more columns that was added in MySQL 5.1.12. For more information, see Section 220.127.116.11, “Replication with Differing Table Definitions on Master and Slave”.
Several programs now accept
--debug-info options: mysql,
and mysqltest already accepted
prints debugging information at program exit.
--debug-info is similar but also prints memory
and CPU usage statistics. This patch also corrects a problem for
not display statistics at exit time.
--syslog option that was
introduced in 5.1.20 for mysqld_safe (to send
error output to
syslog) did not work
correctly: Error output was buffered and not logged immediately.
This has been corrected. In addition, some feature changes were
Transaction support in the
engine has been disabled due to issues with multiple active
transactions and sessions on the same
Previously, prepared statements processed using
EXECUTE were not subject to
caching in the query cache if they contained any
? parameter markers. This limitation has been
It is now possible to set
long_query_time in microseconds
or to 0. Setting this value to 0 causes all queries to be
recorded in the slow query log.
Currently, fractional values can be used only when logging to files. We plan to provide this functionality for logging to tables when time-related data types are enhanced to support microsecond resolution. (Bug#25412)
INFORMATION_SCHEMA implementation changes
were made that optimize certain types of queries for
INFORMATION_SCHEMA tables so that they
execute more quickly.
Section 7.2.20, “
INFORMATION_SCHEMA Optimization”, provides
guidelines on how to take advantage of these optimizations by
writing queries that minimize the need for the server to access
the file system to obtain the information contained in
INFORMATION_SCHEMA tables. By writing queries
that enable the server to avoid directory scans or opening table
files, you will obtain better performance.
Log table locking was redesigned, eliminating several lock-related problems:
mysql.slow_log in a stored
procedure after use of a cursor caused the thread to lock.
Flushing a log table resulted in unnecessary warnings.
Changing the value of the
general_log system variable
while a global read lock was in place resulted in deadlock.
The changes provide better-defined interface characteristics. See Section 5.2.1, “Selecting General Query and Slow Query Log Output Destinations”. (Bug#17876, Bug#23044, Bug#25422, Bug#29129)
Two options relating to slow query logging have been added for
--log-slow-slave-statements causes slow
statements executed by a replication slave to be written to the
slow query log;
min_examined_row_limit can be
used to cause queries which examine fewer than the stated number
of rows not to be logged.
Failure to consider collation when comparing space characters
could result in incorrect index entry order, leading to
incorrect comparisons, inability to find some index values,
misordered index entries, misordered
results, or tables that
TABLE reports as having corrupt indexes.
As a result of this bug fix, indexes must be rebuilt for columns
that use any of these character sets:
Section 2.4.3, “Checking Whether Tables or Indexes Must Be Rebuilt”.
Incompatible Change: Several issues were identified for stored programs (stored procedures and functions, triggers, and events) and views containing non-ASCII symbols. These issues involved conversion errors due to incomplete character set information when translating these objects to and from stored format, such as:
Parsing the original object definition so that it can be stored.
Compiling the stored definition into executable form when the object is invoked.
Retrieval of object definitions from
The fix for the problems is to store character set information from the object creation context so that this information is available when the object needs to be used later. The context includes the client character set, the connection character set and collation, and the collation of the database with which the object is associated.
As a result of the patch, several tables have new columns:
VIEWS table now has these
EVENTS tables now have these
These columns store the session values of the
variables, and the collation of the database with which the
object is associated. The values are those in effect at object
creation time. (The saved database collation is not the value of
variable, which applies to the default database; the database
that contains the object is not necessarily the default
SHOW statements now
display additional columns corresponding to the new table
columns. These statements are:
SHOW FUNCTION STATUS,
SHOW PROCEDURE STATUS,
Subsequent to the patch just described, it was discovered that the patch broke mysql_upgrade; this has been corrected.
The fixes for the problems just describe affect
all existing stored programs and views.
(For example, you will see warnings about “no creation
context.”) To avoid warnings from the server about the
use of old definitions from any release prior to 5.1.21, you
should dump stored programs and views with
mysqldump after upgrading to 5.1.21, and
then reload them to recreate them with new definitions. Invoke
mysqldump with a
--default-character-set option that names the
non-ASCII character set that was used for the definitions when
the objects were originally defined.
DELETE FROM , where the
value_list contained more than one
value, called from an
AFTER DELETE trigger on
NDB table, caused
mysqld to crash.
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. (Bug#29364)
MySQL Cluster: Replica redo logs were inconsistently handled during a system restart. (Bug#29354)
When a node failed to respond to a
signal as part of a global checkpoint, the master node was
killed instead of the node that actually failed.
An invalid comparison made during
validation that could lead to an Error while reading
REDO log condition.
MySQL Cluster: The wrong data pages were sometimes invalidated following a global checkpoint. (Bug#29067)
If at least 2 files were involved in
invalidation, then file 0 of page 0 was not updated and so
pointed to an invalid part of the redo log.
MySQL Cluster: If a storage engine has its own logging capability, then any statement using both this engine and some other engine not having its own logging could not be correctly logged, due to the fact that entries from one engine could be logged before entries from the other engine were. This did not generate any error messages when it occurred.
Now, if multiple storage engines are used in a statement and at least one of them has its own logging capability, then an error message is generated and the statement is not executed.
Currently, the only storage engine to have its own logging
Warnings and errors generated by ndb_config
were sent to
stdout, rather than to
When a cluster backup was terminated using the
BACKUP command in the management client, a misleading
error message Backup aborted by application:
Permanent error: Internal error was returned. The
error message returned in such cases now reads Backup
aborted by user request.
MySQL Cluster: Large file support did not work in AIX server binaries. (Bug#10776)
Replication: Storage engine error conditions in row-based replication were not correctly reported to the user. (Bug#29570)
INSERT DELAYED statements on a
master server are replicated as non-
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
An error that happened inside
DELETE statements performed from
within a stored function or trigger could cause inconsistency
between master and slave servers.
Replication: Slave servers could incorrectly interpret an out-of-memory error from the master and reconnect using the wrong binary log position. (Bug#24192)
Disk Data: Performing Disk Data schema operations during a node restart could cause forced shutdowns of other data nodes. (Bug#29501)
Disk Data: When dropping a page, the stack's bottom entry could sometime be left “cold” rather than “hot”, violating the rules for stack pruning. (Bug#29176)
Disk Data: The number of free extents was incorrectly reported for some tablespaces. (Bug#28642)
mysqld would segfault on startup when the
NDB storage engine was enabled and
the default character set was a strictly multi-byte character
set such as UCS2.
This issue does not apply to character sets that can contain single-byte characters in addition to multi-byte characters such as UTF-8.
Additional issues remain with regard to the use of multi-byte character sets in MySQL Cluster Replication; see Section 17.6.3, “Known Issues in MySQL Cluster Replication”, for more information. (Bug#27404)
Use of local variables with non-ASCII names in stored procedures crashed the server. (Bug#30120)
On Windows, client libraries lacked symbols required for linking. (Bug#30118)
--myisam-recover='' (empty option value) did
SHOW TABLE TYPES statement, the
server sent incorrect output to clients, possibly causing them
REPAIR TABLE ... USE_FRM could corrupt
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.
DISTINCT could cause incorrect rows to
appear in a query result.
On Windows, the CMake build process did not produce the embedded server library or related binaries. (Bug#29903)
Very long prepared statements in stored procedures could cause a server crash. (Bug#29856)
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 table corruption. (Bug#29838)
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. (Bug#29834)
An assertion failure occurred within yaSSL for very long keys. (Bug#29784)
For a table with a
date_col such that selecting rows
a nonempty result, adding
caused the result
to be empty.
Single-row inserts could report a row count greater than one. (Bug#29692)
On 64-bit platforms, the filesort code (for queries with
GROUP BY or
could crash due to an incorrect pointer size.
A left join between two views could produce incorrect results. (Bug#29604)
Certain statements with unions, subqueries, and joins could result in huge memory consumption. (Bug#29582)
Clients using SSL could hang the server. (Bug#29579)
gcov coverage-testing information was not written if the server crashed. (Bug#29543)
ascii character set, conversion of DEL
0x7F) to Unicode incorrectly resulted in
QUESTION MARK (
0x3F) rather than DEL.
A field packet with
NULL fields caused a
The full-text parser could enter an infinite loop if it encountered an illegal multi-byte sequence or a sequence that has no mapping to Unicode. (Bug#29464)
FULLTEXT index for a word with
the boolean mode truncation operator could cause an infinite
Corrupt data resulted from use of
SELECT ... INTO
OUTFILE ', where
file_name' FIELDS ENCLOSED
c is a digit or minus sign, followed
LOAD DATA INFILE
file_name' FIELDS ENCLOSED BY
Deleting from a
CSV table could corrupt it.
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
ORDER BY clause in its
The special “zero”
ENUM value was coerced to the
normal empty string
during a column-to-column copy. This affected
... SELECT statements and
SELECT statements with aggregate
ENUM columns in the
GROUP BY clause.
Inserting a negative number into a
could corrupt it.
Optimization of queries with
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.
FULLTEXT indexes could be corrupted by
SELECT ... INTO
OUTFILE followed by
DATA could result in garbled characters when the
FIELDS ENCLOSED BY clause named a delimiter
'Z' due to an interaction of character
encoding and doubling for data values containing the enclosed-by
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.
Many threads accessing a
simultaneously could cause an assertion failure.
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
TABLE to modify the column definition caused the 0
values to be given the numeric value of the nonzero
Mixing binary and
utf8 columns in a union
caused field lengths to be calculated incorrectly, resulting in
AsText() could fail with a buffer overrun.
Under some circumstances, a
SELECT ... FROM
mysql.event could cause the server to crash.
InnoDB refused to start on some versions of
FreeBSD with LinuxThreads. This is fixed by enabling file
locking on FreeBSD.
A network structure was initialized incorrectly, leading to embedded server crashes. (Bug#29117)
An assertion failure occurred if a query contained a conjunctive
predicate of the form
view_column = constant
WHERE clause and the
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
WHERE clause and
GROUP BY clause contained a reference to
the same view column.
A maximum of 4TB
InnoDB free space was
SHOW TABLE STATUS, which is
incorrect on systems with more than 4TB space.
... SELECT statement inserted into the same table that
SELECT retrieved from, and
ORDER BY and
clauses, different data was inserted than the data produced by
SELECT executed by itself.
A byte-order issue in writing a spatial index to disk caused bad index files on some systems. (Bug#29070)
Creation of a legal stored procedure could fail if no default database had been selected. (Bug#29050)
Updates to a
CSV table could cause a server
crash or update the table with incorrect values.
Dropping the definer of an active event caused the server to crash. (Bug#28924)
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
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.8, “String Repertoire”). (Bug#28875)
In strict SQL mode, errors silently stopped the SQL thread even
for errors named using the
ALTER TABLE (that works
without rebuilding the table) acquired duplicate locks in the
storage engine. In
ALTER TABLE was issued under
TABLE, it caused all data inserted after
TABLE to disappear.
Creating an event to be executed at a time close to the end of the allowed range (2038-01-19 03:14:07 UTC) would cause the server to crash. (Bug#28641)
InnoDB tables, MySQL unnecessarily sorted
records in certain cases when the records were retrieved by
InnoDB in the proper order already.
On Mac OS X, shared-library installation path names were incorrect. (Bug#28544)
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
since this option also invokes
InnoDB could crash if the server was shut
innodb_table_monitor was running.
A race condition in the interaction between
MyISAM and the query cache code caused the
query cache not to invalidate itself for concurrently inserted
A duplicate-key error message could display an incorrect key value when not all columns of the key were used to select rows for update. (Bug#28158)
Indexing column prefixes in
could cause table corruption.
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. (Bug#28125)
Dropping a user-defined function could cause a server crash if the function was still in use by another thread. (Bug#27564)
For some event-creation problems, the server displayed messages that implied the problems were errors when they were only warnings. (Bug#27406)
Unsafe aliasing in the source caused a client library crash when compiled with gcc 4 at high optimization levels. (Bug#27383)
Index-based range reads could fail for comparisons that involved
contraction characters (such as
ch in Czech
ll in Spanish).
Aggregations in subqueries that refer to outer query columns were not always correctly referenced to the proper outer query. (Bug#27333)
Error returns from the
time() system call
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
The server acquired a global mutex for temporary tables, although such tables are thread-specific. This affected performance by blocking other threads. (Bug#27062)
FEDERATED tables had an artificially low
maximum of key length.
Updates to rows in a partitioned table could update the wrong column. (Bug#26827)
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
.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
The Windows implementation of
was incorrect and could cause crashes.
If an operation had an
InnoDB table, and two
AFTER UPDATE and
INSERT, competing for different resources (such as two
MyISAM tables), the triggers were
unable to execute concurrently. In addition,
UPDATE statements for the
InnoDB table were unable to run concurrently.
The index merge union access algorithm could produce incorrect
InnoDB tables. The problem could
also occur for queries that used
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
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,
could kill itself when attempting to kill other processes.
InnoDB assertion failures were
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
For a multiple-row insert into a
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.
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 limitations:
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
... ON DUPLICATE KEY UPDATE.
FEDERATED storage engine failed silently
... ON DUPLICATE KEY UPDATE if a duplicate key
FEDERATED does not
ON DUPLICATE KEY UPDATE, so now it
correctly returns an
error if a duplicate key violation occurs.
In a stored function or trigger, when
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
InnoDB above the function/trigger
On Windows, executables did not include Vista manifests. (Bug#24732)
See also Bug#22563.
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. Now, if the redo
log scan at
InnoDB startup goes past the last
checkpoint, crash recovery is forced.
When determining which transaction to kill after deadlock has
InnoDB now adds the number of
locks to a transaction's weight, and avoids killing transactions
that mave modified nontransactional tables. This should reduce
the likelihood of killing long-running transactions containing
SELECT ... FOR
INSERT/REPLACE INTO ...
SELECT statements, and of causing partial updates if
the target is a
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). (Bug#21074)
See also Bug#39253.
On Windows, the server used 10MB of memory for each connection thread, resulting in memory exhaustion. Now each thread uses 1MB. (Bug#20815)
InnoDB produced an unnecessary (and harmless)
InnoDB: Error: trying to
declare trx to enter
InnoDB: it already is declared
If a slave timed out while registering with the master to which it was connecting, auto-reconnect failed thereafter. (Bug#19328)
InnoDB reached its limit on the number of
concurrent transactions (1023), it wrote a descriptive message
to the error log but returned a misleading error message to the
client, or an assertion failure occurred.
See also Bug#46672.
Under ActiveState Perl,
would not run.
The server crashed when the size of an
ARCHIVE table grew larger than 2GB.
SQL_BIG_RESULT had no effect for
CREATE TABLE ... SELECT SQL_BIG_RESULT ...
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.
For the general query log, logging of prepared statements
executed via the C API differed from logging of prepared
statements performed with
EXECUTE. Logging for the
latter was missing the
See also Bug#32440.
Backup software can cause
ERROR_LOCK_VIOLATION conditions during file
InnoDB now retries forever until
the condition goes away.