Dear MySQL users,
We are proud to present to you the MySQL Server 5.1.21-beta
release, a new beta version of the popular open source database.
Bear in mind that this is a beta release, and as with any other
pre-production release, caution should be taken when installing on
production level systems or systems with critical data. For production
level systems using 5.0, we would like to direct your attention to the
product description of MySQL Enterprise at:
http://mysql.com/products/enterprise/
The MySQL 5.1.21-beta release is now available in source and binary form
for a number of platforms from our download pages at
http://dev.mysql.com/downloads/
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.
Please also note that some of our mirrors are currently experiencing
problems that may result in serving corrupted files. We are working with
the mirror maintainers to resolve this.
We welcome and appreciate your feedback, bug reports, bug fixes,
patches etc.:
http://forge.mysql.com/wiki/Contributing
The following section lists the changes from version to version in the
MySQL source code since the latest released version of MySQL 5.1, the
MySQL 5.1.20-beta release. It can also be viewed online at
http://dev.mysql.com/doc/refman/5.1/en/news-5-1-21.html
Functionality added or changed:
* Incompatible change: 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 this release, no logging
option changes should be necessary. However, if you are
upgrading from 5.1.6 through 5.1.20 to this release and were
using TABLE logging, use the --log-output=TABLE option
explicitly to preserve your server's table-logging behavior.
(Bug#29993: http://bugs.mysql.com/29993)
* The --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 made:
+ Important: The default mysqld_safe logging behavior now
is --skip-syslog rather than --syslog, which is
compatible with the default behavior of writing an error
log file for releases prior to 5.1.20.
+ A new option, --syslog-tag=tag, modifies the default tags
written by mysqld_safe and mysqld to syslog to be
mysqld_safe-tag and mysqld-tag rather than the default
tags of mysqld_safe and mysqld.
(Bug#29992: http://bugs.mysql.com/29992)
* Several programs now accept --debug-check and --debug-info
options: mysql, mysqladmin, mysqlbinlog, mysqlcheck,
mysqldump, mysqlimport, mysqlshow, mysqlslap, mysqltest,
mysql_upgrade. (Note: mysql and mysqltest already accepted
--debug-info.) --debug-check 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 mysql that --debug-info did not display statistics at exit
time. (Bug#30127: http://bugs.mysql.com/30127)
* Transaction support in the FEDERATED storage engine has been
disabled due to issues with multiple active transactions and
sessions on the same FEDERATED table.
(Bug#29875: http://bugs.mysql.com/29875)
* Previously, prepared statements processed using PREPARE and
EXECUTE were not subject to caching in the query cache if they
contained any ? parameter markers. This limitation has been
lifted. (Bug#29318: http://bugs.mysql.com/29318)
* 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 15.3.1.19, "Replication with Fewer
Columns on the Slave."
* The SQL thread on a slave now is always allowed to enter
InnoDB even if this would exceed the limit imposed by the
innodb_thread_concurrency system variable. In cases of high
load on the slave server (when innodb_thread_concurrency is
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
slave server. (Bug#25078: http://bugs.mysql.com/25078)
Bugs fixed:
* Incompatible change: Several issues were identified for stored
programs (stored functions and procedures, 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 INFORMATION_SCHEMA
tables.
+ Displaying the object definition in SHOW statements. This
issue also affected mysqldump, which uses SHOW.
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:
+ In the mysql database, the proc and event tables now have
these columns: character_set_client,
collation_connection, db_collation, body_utf8.
+ In INFORMATION_SCHEMA, the VIEWS table now has these
columns: CHARACTER_SET_CLIENT, COLLATION_CONNECTION. The
ROUTINES, TRIGGERS, and EVENT tables now have these
columns: CHARACTER_SET_CLIENT, COLLATION_CONNECTION,
DATABASE_COLLATION.
These columns store the session values of the
character_set_client and collation_connection system
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 the collation_database system variable, which applies to
the default database; the database that contains the object is
not necessarily the default database.)
Several SHOW statements now display additional columns
corresponding to the new table columns. These statements are:
SHOW CREATE EVENT, SHOW CREATE FUNCTION, SHOW CREATE
PROCEDURE, SHOW CREATE VIEW, SHOW EVENTS, SHOW FUNCTION
STATUS, SHOW PROCEDURE STATUS, SHOW TRIGGERS.
A new statement, SHOW CREATE TRIGGER is introduced and is used
by mysqldump for producing CREATE TRIGGER statements.
(Bug#11986: http://bugs.mysql.com/11986,
Bug#16291: http://bugs.mysql.com/16291,
Bug#19443: http://bugs.mysql.com/19443,
Bug#21249: http://bugs.mysql.com/21249,
Bug#25212: http://bugs.mysql.com/25212,
Bug#25221: http://bugs.mysql.com/25221,
Bug#30027: http://bugs.mysql.com/30027)
Subsequent to the patch just described, it was discovered that
the patch broke mysql_upgrade; this has been corrected.
(Bug#30029: http://bugs.mysql.com/30029)
Important: 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.
* NDB Cluster: The server would not compile with NDB support on
AIX 5.2. (Bug#10776: http://bugs.mysql.com/10776)
* NDB Cluster (Replication): Inconsistencies could occur between
the master and the slave when replicating Disk Data tables.
(Bug#19259: http://bugs.mysql.com/19259)
* NDB Cluster (Replication): 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. (Bug#27404: http://bugs.mysql.com/27404)
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
16.10.3, "Known Issues in MySQL Cluster Replication," for more
information.
* NDB Cluster: Warnings and errors generated by
ndb_config --config-file=file
were sent to stdout rather than stderr.
(Bug#25941: http://bugs.mysql.com/25941)
* NDB Cluster (Disk Data): Performing Disk Data schema
operations during a node restart could cause forced shutdowns
of other data nodes. (Bug#29501: http://bugs.mysql.com/29501)
* NDB Cluster (Disk Data): Disk data meta-information that
existed in ndbd might not be visible to mysqld.
(Bug#28720: http://bugs.mysql.com/28720)
* NDB Cluster (Disk Data): The number of free extents was
incorrectly reported for some tablespaces.
(Bug#28642: http://bugs.mysql.com/28642)
* NDB Cluster (Cluster Replication): When executing a statement
where binlog_format=statement, the result of the statement was
logged both as a statement and as rows.
(Bug#29222: http://bugs.mysql.com/29222)
* NDB Cluster: Replica redo logs were inconsistently handled
during a system restart.
(Bug#29354: http://bugs.mysql.com/29354)
* NDB Cluster: When restarting a data node, queries could hang
during that node's start phase 5, and only continue once the
node entered phase 6. (Bug#29364: http://bugs.mysql.com/29364)
* NDB Cluster: When a node failed to respond to a COPY_GCI
signal as part of a global checkpoint, the master node was
killed instead instead of the node that actually failed.
(Bug#29331: http://bugs.mysql.com/29331)
* NDB Cluster: An invalid comparison made during REDO validation
that could lead to an Error while reading REDO log condition.
(Bug#29118: http://bugs.mysql.com/29118)
* NDB Cluster: The wrong data pages were sometimes invalidated
following a global checkpoint.
(Bug#29067: http://bugs.mysql.com/29067)
* NDB Cluster: If at least 2 files were involved in REDO
invalidation, then file 0 of page 0 was not updated and so
pointed to an invalid part of the redo log.
(Bug#29057: http://bugs.mysql.com/29057)
* The server acquired a global mutex for temporary tables,
although such tables are thread-specific. This affected
performance by blocking other threads.
(Bug#27062: http://bugs.mysql.com/27062)
* 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. (Bug#29152: http://bugs.mysql.com/29152)
* 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: http://bugs.mysql.com/29838)
* On Windows, client libraries lacked symbols required for
linking. (Bug#30118: http://bugs.mysql.com/30118)
* On Windows, the CMake build process did not produce the
embedded server library or related binaries.
(Bug#29903: http://bugs.mysql.com/29903)
* SESSION_USER() returned garbage data (rather than the correct
value of the empty string) when executed by a slave SQL
thread. (Bug#29878: http://bugs.mysql.com/29878)
* For the SHOW TABLE TYPES statement, the server sent incorrect
output to clients, possibly causing them to crash.
(Bug#30036: http://bugs.mysql.com/30036)
* 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.6, "String Repertoire").
(Bug#28875: http://bugs.mysql.com/28875)
* REPAIR TABLE ... USE_FRM could corrupt tables.
(Bug#29980: http://bugs.mysql.com/29980)
* FEDERATED tables had an artificially low maximum of key
length. (Bug#26909: http://bugs.mysql.com/26909)
* 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)
* 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.
(Bug#24989: http://bugs.mysql.com/24989)
* --myisam-recover="" (empty option value) did not disable
MyISAM recovery. (Bug#29856: http://bugs.mysql.com/29856)
* Very long prepared statements in stored procedures could cause
a server crash. (Bug#29856: http://bugs.mysql.com/29856)
* 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: http://bugs.mysql.com/28125)
* mysql_setpermission tried to grant global-only privileges at
the database level. (Bug#14618: http://bugs.mysql.com/14618)
* 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)
* An assertion failure occurred within yaSSL for very long keys.
(Bug#29784: http://bugs.mysql.com/29784)
* 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: http://bugs.mysql.com/29834)
* The IS_UPDATABLE column in the INFORMATION_SCHEMA.VIEWS table
was not always set correctly.
(Bug#30020: http://bugs.mysql.com/30020)
* 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)
* InnoDB could crash if the server was shut down while
innodb_table_monitor was running.
(Bug#28254: http://bugs.mysql.com/28254)
* 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)
* Certain statements with unions, subqueries, and joins could
result in huge memory consumption.
(Bug#29582: http://bugs.mysql.com/29582)
* SHOW statements were being written to the slow query log that
should not have been. (Bug#30000: http://bugs.mysql.com/30000)
* Use of local variables with non-ASCII names in stored
procedures crashed the server.
(Bug#30120: http://bugs.mysql.com/30120)
* INSERT ... VALUES(CONNECTION_ID(), ...) statements were
written to the binary log in such a way that they could not be
properly restored. (Bug#29928: http://bugs.mysql.com/29928)
* Prepared statements containing CONNECTION_ID() could be
written improperly to the binary log.
(Bug#30200: http://bugs.mysql.com/30200)
* mysql_install_db could fail to find script files that it
needs. (Bug#28585: http://bugs.mysql.com/28585)
* On Windows, executables did not include Vista manifests.
(Bug#24732: http://bugs.mysql.com/24732)
* 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)
* On Windows, the server used 10MB of memory for each connection
thread, resulting in memory exhaustion. Now each thread uses
1MB. (Bug#20815: http://bugs.mysql.com/20815)
* Dropping a temporary InnoDB table that had been locked with
LOCK TABLES caused a server crash.
(Bug#24918: http://bugs.mysql.com/24918)
* Log table locking was redesigned, eliminating several
lock-related problems:
+ Truncating mysql.slow_log in a stored procedure after use
of a cursor caused the thread to lock.
(Bug#17876: http://bugs.mysql.com/17876)
+ Flushing a log table resulted in warnings.
(Bug#23044: http://bugs.mysql.com/23044)
+ The server would hang when performing concurrent ALTER
TABLE or TRUNCATE TABLE statements against the log
tables. (Bug#25422: http://bugs.mysql.com/25422)
+ Changing the value of the general_log system variable
while a global read lock was in place resulted in
deadlock. (Bug#29129: http://bugs.mysql.com/29129)
* 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.
(Bug#29929: http://bugs.mysql.com/29929)
* 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: http://bugs.mysql.com/28641)
* On Windows, Instance Manager would crash if an instance object
failed to initialize during startup. This could happen if an
incorrect mysqld path was supplied in the configuration file.
(Bug#28012: http://bugs.mysql.com/28012)
* Instance Manager had a race condition when it received a
shutdown request while a guarded mysqld instance was starting
such that it could fail to stop the mysqld instance.
(Bug#28030: http://bugs.mysql.com/28030)
* 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.
(Bug#28838: http://bugs.mysql.com/28838)
* After the first read of a TEMPORARY table, CHECK TABLE could
report the table as being corrupt.
(Bug#26325: http://bugs.mysql.com/26325)
* 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. (Bug#25679: http://bugs.mysql.com/25679)
* On Mac OS X, shared-library installation pathnames were
incorrect. (Bug#28544: http://bugs.mysql.com/28544)
* For MyISAM tables on Windows, INSERT, DELETE, or UPDATE
followed by ALTER TABLE within LOCK TABLES could cause table
corruption. (Bug#29957: http://bugs.mysql.com/29957)
* When determining which transaction to kill after deadlock has
been detected, InnoDB now adds the number of locks to a
transaction's weight, and avoids killing transactions that
mave modified non-transactional tables. This should reduce the
likelihood of killing long-running transactions containing
SELECT ... FOR UPDATE or INSERT/REPLACE INTO ... SELECT
statements, and of causing partial updates if the target is a
MyISAM table. (Bug#21293: http://bugs.mysql.com/21293)
* 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.
(Bug#25714: http://bugs.mysql.com/25714)
* Optimization of queries with DETERMINISTIC stored functions in
the WHERE clause was ineffective: A sequential scan was always
used. (Bug#29338: http://bugs.mysql.com/29338)
* SQL_BIG_RESULT had no effect for CREATE TABLE ... SELECT
SQL_BIG_RESULT ... statements.
(Bug#15130: http://bugs.mysql.com/15130)
* For InnoDB tables, MySQL unnecessarily sorted records in
certain cases when the records were retrieved by InnoDB in the
proper order already. (Bug#28591: http://bugs.mysql.com/28591)
* 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.
(Bug#29661: http://bugs.mysql.com/29661)
* On Windows, ALTER TABLE hung if records were locked in share
mode by a long-running transaction.
(Bug#29644: http://bugs.mysql.com/29644)
* A field packet with NULL fields caused a libmysqlclient crash.
(Bug#29494: http://bugs.mysql.com/29494)
* A byte-order issue in writing a spatial index to disk caused
bad index files on some systems.
(Bug#29070: http://bugs.mysql.com/29070)
* mysqldump produced output that incorrectly discarded the
NO_AUTO_VALUE_ON_ZERO value of the SQL_MODE variable after
dumping triggers. (Bug#29788: http://bugs.mysql.com/29788)
* Adding DISTINCT could cause incorrect rows to appear in a
query result. (Bug#29911: http://bugs.mysql.com/29911)
* Killing an INSERT DELAYED thread caused a server crash.
(Bug#29431: http://bugs.mysql.com/29431)
* For updates to InnoDB tables, a TIMESTAMP column with the ON
UPDATE CURRENT_TIMESTAMP attribute could be updated even when
no values actually changed.
(Bug#29310: http://bugs.mysql.com/29310)
* 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. (Bug#29360: http://bugs.mysql.com/29360)
* Conversion of ASCII DEL (0x7F) to Unicode incorrectly resulted
in QUESTION MARK (0x3F) rather than DEL.
(Bug#29499: http://bugs.mysql.com/29499)
* A left join between two views could produce incorrect results.
(Bug#29604: http://bugs.mysql.com/29604)
* For MEMORY tables, the index_merge union access method could
return incorrect results.
(Bug#29740: http://bugs.mysql.com/29740)
* 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)
* Slave servers could incorrectly interpret an out-of-memory
error from the master and reconnect using the wrong binary log
position. (Bug#24192: http://bugs.mysql.com/24192)
* 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.
(Bug#29739: http://bugs.mysql.com/29739)
* An incorrect result was returned when comparing string values
that were converted to TIME values with CAST().
(Bug#29555: http://bugs.mysql.com/29555)
* If 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.
(Bug#18828: http://bugs.mysql.com/18828)
* On Windows, the mysql client died if the user entered a
statement and Return after entering Control-C.
(Bug#29469: http://bugs.mysql.com/29469)
* 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.
(Bug#13326: http://bugs.mysql.com/13326)
* 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: http://bugs.mysql.com/21074)
* 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. (Bug#26141: http://bugs.mysql.com/26141)
* On 64-bit platforms, the filesort code (for queries with GROUP
BY or ORDER BY) could crash due to an incorrect pointer size.
(Bug#29610: http://bugs.mysql.com/29610)
* 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.
(Bug#29898: http://bugs.mysql.com/29898)
* 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 --skip-add-drop-table.
(Bug#28524: http://bugs.mysql.com/28524)
* 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.
(Bug#28249: http://bugs.mysql.com/28249)
* 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: http://bugs.mysql.com/29464)
* Failure to consider collation when comparing space characters
could lead to incorrect index entry order, making it
impossible to find some index values.
(Bug#29461: http://bugs.mysql.com/29461)
* Several InnoDB assertion failures were corrected.
(Bug#25645: http://bugs.mysql.com/25645)
* InnoDB displayed an incorrect error message when a CREATE
TABLE statement exceeded the InnoDB maximum allowable row
size. (Bug#21101: http://bugs.mysql.com/21101)
* InnoDB produced an unnecessary (and harmless) warning: InnoDB:
Error: trying to declare trx to enter InnoDB, but InnoDB: it
already is declared. (Bug#20090: http://bugs.mysql.com/20090)
* Backup software can cause ERROR_SHARING_VIOLATION or
ERROR_LOCK_VIOLATION conditions during file operations. InnoDB
now retries forever until the condition goes away.
(Bug#9709: http://bugs.mysql.com/9709)
* In strict SQL mode, errors silently stopped the SQL thread
even for errors named using the --slave-skip-errors option.
(Bug#28839: http://bugs.mysql.com/28839)
* MyISAM corruption could occur with the cp932_japanese_ci
collation for the cp932 character set due to incorrect
comparison for trailing space.
(Bug#29333: http://bugs.mysql.com/29333)
* Searching a FULLTEXT index for a word with the boolean mode
truncation operator could cause an infinite loop.
(Bug#29445: http://bugs.mysql.com/29445)
* CHECK TABLE could erroneously report table corruption for a
CSV table if multiple threads were modifying the table at the
same time. (Bug#29253: http://bugs.mysql.com/29253)
* Clients using SSL could hang the server.
(Bug#29579: http://bugs.mysql.com/29579)
* Single-row inserts could report a row count greater than one.
(Bug#29692: http://bugs.mysql.com/29692)
* 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. (Bug#29729: http://bugs.mysql.com/29729)
* If a stored procedure was created and invoked prior to
selecting a default database with USE, a No database selected
error occurred. (Bug#28551: http://bugs.mysql.com/28551)
* Indexing column prefixes in InnoDB tables could cause table
corruption. (Bug#28138: http://bugs.mysql.com/28138)
* SHOW INNODB STATUS caused an assertion failure under high
load. (Bug#22819: http://bugs.mysql.com/22819)
* If a slave timed out while registering with the master to
which it was connecting, auto-reconnect failed thereafter.
(Bug#19328: http://bugs.mysql.com/19328)
* 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)
* mysql-stress-test.pl and mysqld_multi.server.sh were missing
from some binary distributions.
(Bug#21023: http://bugs.mysql.com/21023,
Bug#25486: http://bugs.mysql.com/25486)
* 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)
* 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: http://bugs.mysql.com/28158)
* For some event-creation problems, the server displayed
messages that implied the problems were errors when they were
only warnings. (Bug#27406: http://bugs.mysql.com/27406)
* Error returns from the time() system call were ignored.
(Bug#27198: http://bugs.mysql.com/27198)
* ALTER DATABASE did not require at least one option.
(Bug#25859: http://bugs.mysql.com/25859)
* Creation of a legal stored procedure could fail if no default
database had been selected.
(Bug#29050: http://bugs.mysql.com/29050)
* mysqld_safe produced error messages and did not create the
error log file under some circumstances.
(Bug#29634: http://bugs.mysql.com/29634)
* The thread ID was not reset properly after execution of
mysql_change_user(), which could cause replication failure
when replicating temporary tables.
(Bug#29734: http://bugs.mysql.com/29734)
* 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. (Bug#25511: http://bugs.mysql.com/25511)
* 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 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 INSERT ... ON
DUPLICATE KEY UPDATE.
(Bug#25513: http://bugs.mysql.com/25513)
* 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.
(Bug#28846: http://bugs.mysql.com/28846)
* Calling mysql_options() after mysql_real_connect() could cause
clients to crash. (Bug#29247: http://bugs.mysql.com/29247)
* 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. (Bug#29251: http://bugs.mysql.com/29251)
* Aggregations in subqueries that refer to outer query columns
were not always correctly referenced to the proper outer
query. (Bug#27333: http://bugs.mysql.com/27333)
* Use of SHOW BINLOG EVENTS for a non-existent log file followed
by PURGE MASTER LOGS caused a server crash.
(Bug#29420: http://bugs.mysql.com/29420)
* A number of unsupported constructs --- including prohibited
constructs, the UCASE() function, and nested function calls
--- were permitted in partitioning expressions.
(Bug#18198: http://bugs.mysql.com/18198,
Bug#26082: http://bugs.mysql.com/26082,
Bug#29308: http://bugs.mysql.com/29308)
* SHOW BINLOG EVENTS displayed incorrect values of End_log_pos
for events associated with transactional storage engines.
(Bug#22540: http://bugs.mysql.com/22540)
* mysqldump created a stray file when a given a too-long
filename argument. (Bug#29361: http://bugs.mysql.com/29361)
* The semantics of BIGINT depended on platform-specific
characteristics. (Bug#29079: http://bugs.mysql.com/29079)
* mysqld failed to exit during shutdown.
(Bug#29133: http://bugs.mysql.com/29133)
* Inserting a negative number into a CSV table could corrupt it.
(Bug#29353: http://bugs.mysql.com/29353)
* Deleting from a CSV table could corrupt it.
(Bug#29411: http://bugs.mysql.com/29411)
* 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.
(Bug#28625: http://bugs.mysql.com/28625)
* Runtime changes to the log_queries_not_using_indexes system
variable were ignored.
(Bug#28808: http://bugs.mysql.com/28808)
* Under ActiveState Perl, mysql-test-run.pl would not run.
(Bug#18415: http://bugs.mysql.com/18415)
* Under ActiveState Perl, mysql-test-run.pl could kill itself
when attempting to kill other processes.
(Bug#25657: http://bugs.mysql.com/25657)
* Assertion failure could occur for grouping queries that
employed DECIMAL user variables with assignments to them.
(Bug#29417: http://bugs.mysql.com/29417)
* For CAST(expr AS DECIMAL(M,D)), the limits of 65 and 30 on the
precision (M) and scale (D) were not enforced.
(Bug#29415: http://bugs.mysql.com/29415)
* 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'. (Bug#29442: http://bugs.mysql.com/29442)
* AsText() could fail with a buffer overrun.
(Bug#29166: http://bugs.mysql.com/29166)
* 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)
* The index merge union access algorithm could produce incorrect
results with InnoDB tables. The problem could also occur for
queries that used DISTINCT.
(Bug#25798: http://bugs.mysql.com/25798)
* 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)
* gcov coverage-testing information was not written if the
server crashed. (Bug#29543: http://bugs.mysql.com/29543)
* FULLTEXT indexes could be corrupted by certain gbk characters.
(Bug#29299: http://bugs.mysql.com/29299)
* REPLACE, INSERT IGNORE, and UPDATE IGNORE did not work for
FEDERATED tables. (Bug#29019: http://bugs.mysql.com/29019)
* CHECK TABLE for ARCHIVE tables could falsely report table
corruption or cause a server crash.
(Bug#29207: http://bugs.mysql.com/29207)
* SELECT ... FOR UPDATE with partitioned tables could cause a
server crash. (Bug#28026: http://bugs.mysql.com/28026)
* Updates to rows in a partitioned table could update the wrong
column. (Bug#26827: http://bugs.mysql.com/26827)
* Updates to a CSV table could cause a server crash or update
the table with incorrect values.
(Bug#28971: http://bugs.mysql.com/28971)
* Dropping a user-defined function could cause a server crash if
the function was still in use by another thread.
(Bug#27564: http://bugs.mysql.com/27564)
* The server crashed when the size of an ARCHIVE table grew
larger than 2GB. (Bug#15787: http://bugs.mysql.com/15787)
* 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)
* Replication of partitioned tables using the InnoDB storage
engine failed with binlog-format=ROW or binlog-format=MIXED.
(Bug#28430: http://bugs.mysql.com/28430)
* 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.
(Bug#28722: http://bugs.mysql.com/28722)
Note:
Currently, the only storage engine to have its own logging
capability is NDBCLUSTER.
* Using the READ COMMITTED transaction isolation level caused
mixed and statement-based replication to fail.
(Bug#23051: http://bugs.mysql.com/23051)
* The server returned data from SHOW CREATE TABLE statement or a
SELECT statement on an INFORMATION_SCHEMA table using the
binarycharacterset.(Bug#10491: http://bugs.mysql.com/10491)
* 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)
* LOCK TABLES was not atomic when more than one InnoDB tables
were locked. (Bug#29154: http://bugs.mysql.com/29154)
* 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.
(Bug#29087: http://bugs.mysql.com/29087)
* Selecting a column not present in the selected-from table
caused an extra error to be produced by SHOW ERRORS.
(Bug#28677: http://bugs.mysql.com/28677)
* 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)
* 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.
(Bug#14649: http://bugs.mysql.com/14649)
* 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.
(Bug#28898: http://bugs.mysql.com/28898)
* 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.
(Bug#28925: http://bugs.mysql.com/28925)
* 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)
* The Windows implementation of pthread_join() was incorrect and
could cause crashes. (Bug#26564: http://bugs.mysql.com/26564)
* 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.
(Bug#29261: http://bugs.mysql.com/29261)
* Many threads accessing a CSV table simultaneously could cause
anassertionfailure.(Bug#29252: http://bugs.mysql.com/29252)
* mysqlbinlog --hexdump generated incorrect output due to
omission of the `#' comment character for some comment lines.
(Bug#28293: http://bugs.mysql.com/28293)
* 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)
* Dropping the definer of an active event caused the server to
crash. (Bug#28924: http://bugs.mysql.com/28924)
* Executing ALTER EVENT on an event whose definer's event
creation privileges had been revoked cause the server to
crash. (Bug#28873: http://bugs.mysql.com/28873)
* Creating an event using ON SCHEDULE AT CURRENT_TIMESTAMP +
INTERVAL ... could in some cases cause mysqld to crash.
(Bug#28881: http://bugs.mysql.com/28881)
* Under some circumstances, a SELECT ... FROM mysql.event could
cause the server to crash.
(Bug#29156: http://bugs.mysql.com/29156)
* Some functions when used in partitioning expressions could
cause mysqld to crash.
(Bug#27084: http://bugs.mysql.com/27084)
* The SUBSTRING() function returned the 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'.
(Bug#27130: http://bugs.mysql.com/27130)
* 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)
* 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.
(Bug#25602: http://bugs.mysql.com/25602)
* A network structure was initialized incorrectly, leading to
embedded server crashes.
(Bug#29117: http://bugs.mysql.com/29117)
* Fixed a case of unsafe aliasing in the source that caused a
client library crash when compiled with gcc 4 at high
optimization levels. (Bug#27383: http://bugs.mysql.com/27383)
Enjoy !
Joerg
--
Joerg Bruehe, Senior Production Engineer
MySQL AB, www.mysql.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
