|| ||Daniel Fischer <df-AT-mysql.com>|
|| ||announce-AT-lists.mysql.com, mysql-AT-lists.mysql.com, packagers-AT-lists.mysql.com,
|| ||MySQL Community Server 5.0.45 has been released!|
|| ||Thu, 12 Jul 2007 10:19:41 +0200|
Dear MySQL users,
MySQL Community Server 5.0.45, a new version of the popular Open Source
Database Management System, has been released. The release is now
available in source and binary form 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.
This release includes a number of security-relevant fixes:
* CREATE TABLE LIKE did not require any privileges on the source
table and was not isolated from alteration by other connections.
(Bugs #25578 and #23667)
* It is no longer possible to use a view to gain update privileges
for tables in other databases. (Bug#27878)
* It is no longer possible for a user to gain privileges by calling
a stored routine that was declared using SQL SECURITY INVOKER.
* The DROP privilege requirement for RENAME TABLE is now correctly
* Malformed password packets in the connection protocol can no longer
cause the server to crash. (Bug#28984)
One bug fix resulted in an incompatible change:
* The use of an ORDER BY or DISTINCT clause with a query containing
a call to the GROUP_CONCAT() function caused results from previous
queries to be redisplayed in the current result. The fix for this
includes replacing a BLOB value used internally for sorting with a
VARCHAR; this may lead to truncation when the result of a query
that uses GROUP_CONCAT() is longer than the limit for VARCHAR,
which is a new restriction in MySQL 5.0.45.
(Bugs #23856, #28273)
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.41 release.
It can also be viewed online at
Functionality added or changed:
* Binaries for the Linux x86 statically linked tar.gz Community
package were linked dynamically, not statically. Static
linking has been re-enabled.
Functionality added or changed from 5.0.44 (Enterprise version):
* A new status variable, Com_call_procedure, indicates the
number of calls to stored procedures.
* NDB Cluster: The server source tree now includes scripts to
simplify building MySQL with SCI support. For more information
about SCI interconnects and these build scripts, see Section
15.9.1, "Configuring MySQL Cluster to use SCI Sockets."
Functionality added or changed from 5.0.42 (Enterprise version):
* Prior to this release, when DATE values were compared with
DATETIME values the time portion of the DATETIME value was
ignored. Now a DATE value is coerced to the DATETIME type by
adding the time portion as "00:00:00". To mimic the old
behavior use the CAST() function in the following way: SELECT
date_field = CAST(NOW() as DATE);. (Bug# 28929)
* Binaries for the Linux x86 statically linked tar.gz Community
package were linked dynamically, not statically. Static
linking has been re-enabled.
* Potential memory leaks in the SHOW PROFILE implementation were
eliminated. (Bug#24795: http://bugs.mysql.com/24795)
* Times displayed by SHOW PROFILE were incorrectly associated
with the profile entry one later than the corrrect one.
* SHOW PROFILE hung if executed before enabling the @@profiling
session variable. (Bug#26938: http://bugs.mysql.com/26938)
Bug fixes from 5.0.44 (Enterprise version):
* Security fix: A malformed password packet in the connection
protocol could cause the server to crash. Thanks for Dormando
for reporting this bug and providing details and a proof of
concept. (Bug#28984: http://bugs.mysql.com/28984)
* Security Fix: CREATE TABLE LIKE did not require any privileges
on the source table. (Bug#25578: http://bugs.mysql.com/25578)
In addition, CREATE TABLE LIKE was not isolated from
alteration by other connections, which resulted in various
errors and incorrect binary log order when trying to execute
concurrently a CREATE TABLE LIKE statement and either DDL
statements on the source table or DML or DDL statements on the
target table. (Bug#23667: http://bugs.mysql.com/23667)
* Incompatible change: The use of an ORDER BY or DISTINCT clause
with a query containing a call to the GROUP_CONCAT() function
caused results from previous queries to be redisplayed in the
current result. The fix for this includes replacing a BLOB
value used internally for sorting with a VARCHAR. This means
that for long results (more than 65,535 bytes), it is possible
for truncation to occur; if so, an appropriate warning is
issued. (Bug#23856: http://bugs.mysql.com/23856,
* NDB Cluster: A race condition could result when non-master
nodes (in addition to the master node) tried to update active
status due to a local checkpoint. Now only the master updates
the active status. (Bug#28717: http://bugs.mysql.com/28717)
* NDB Cluster: The actual value of MaxNoOfOpenFiles as used by
the cluster was offset by 1 from the value set in config.ini.
This meant that setting InitialNoOpenFilesto the same value
always caused an error.
* NDB Cluster: A fast global checkpoint under high load with a
high usage of the redo buffer caused data nodes to fail.
* NDB Cluster: UPDATE IGNORE statements involving the primary
keys of multiple tables could result in data corruption.
* NDB Cluster : A corrupt schema file could cause a File already
open error. (Bug#28770: http://bugs.mysql.com/28770)
* NDB Cluster: When an API node sent more than 1024 signals in a
single batch, NDB would process only the first 1024 of these,
and then hang. (Bug#28443: http://bugs.mysql.com/28443)
* NDB Cluster: A failure to release internal resources following
an error could lead to problems with single user mode.
* NDB Cluster: A delay in obtaining AUTO_INCREMENT IDs could
lead to excess temporary errors.
* The -lmtmalloc library was removed from the output of
mysql_config on Solaris, as it caused problems when building
DBD::mysql (and possibly other applications) on that platform
that tried to use dlopen() to access the client library.
* On Windows, connection handlers did not properly decrement the
server's thread count when exiting.
* On Windows, USE_TLS was not defined for mysqlclient.lib.
* INSERT .. ON DUPLICATE KEY UPDATE could under some
circumstances silently update rows when it should not have.
* Connections from one mysqld server to another failed on Mac OS
X, affecting replication and FEDERATED tables.
* The "manager thread" of the LinuxThreads implementation was
unintentionally started before mysqld had dropped privileges
(to run as an unprivileged user). This caused signaling
between threads in mysqld to fail when the privileges were
finally dropped. (Bug#28690: http://bugs.mysql.com/28690)
* A query that grouped by the result of an expression returned a
different result when the expression was assigned to a user
variable. (Bug#28494: http://bugs.mysql.com/28494)
* The result of evaluation for a view's CHECK OPTION option over
an updated record and records of merged tables was arbitrary
and dependant on the order of records in the merged tables
during the execution of the SELECT statement.
* Outer join queries with ON conditions over constant outer
tables did not return NULL-complemented rows when conditions
were evaluated to FALSE.
* An update on a multiple-table view with the CHECK OPTION
clause and a subquery in the WHERE condition could cause an
assertion failure. (Bug#28561: http://bugs.mysql.com/28561)
* mysql_affected_rows() could return an incorrect result for
INSERT ... ON DUPLICATE KEY UPDATE if the CLIENT_FOUND_ROWS
flag was set. (Bug#28505: http://bugs.mysql.com/28505)
* Storing a large number into a FLOAT or DOUBLE column with a
fixed length could result in incorrect truncation of the
number if the columns's length was greater than 31.
* HASH indexes on VARCHAR columns with binary collations did not
ignore trailing spaces from strings before comparisons. This
could result in duplicate records being successfully inserted
into a MEMORY table with unique key constraints. A consequence
was that internal MEMORY tables used for GROUP BY calculation
contained duplicate rows that resulted in duplicate-key errors
when converting those temporary tables to MyISAM, and that
error was incorrectly reported as a table is full error.
* ON conditions from JOIN expressions were ignored when checking
the CHECK OPTION clause while updating a multiple-table view
that included such a clause.
* The IS_UPDATABLE column in the INFORMATION_SCHEMA.VIEWS table
was not always set correctly.
* For CAST() of a NULL value with type DECIMAL, the return value
was incorrectly initialized, producing a runtime error for
binaries built using Visual C++ 2005.
* DECIMAL values beginning with nine 9 digits could be
incorrectly rounded. (Bug#27984: http://bugs.mysql.com/27984)
* For debug builds, ALTER TABLE could trigger an assertion
failure due to occurrence of a deadlock when committing
changes. (Bug#28652: http://bugs.mysql.com/28652)
* Searches on indexed and non-indexed ENUM columns could return
different results for empty strings.
* If a stored function or trigger was killed, it aborted but no
error was thrown, allowing the calling statement to continue
without noticing the problem. This could lead to incorrect
results. (Bug#27563: http://bugs.mysql.com/27563)
* When ALTER TABLE was used to add a new DATE column with no
explicit default value, '0000-00-00' was used as the default
even if the SQL mode included the NO_ZERO_DATE mode to
prohibit that value. A similar problem occurred for DATETIME
columns. (Bug#27507: http://bugs.mysql.com/27507)
* Statements within triggers ignored the value of the
low_priority_updates system variable.
* Queries that used UUID() were incorrectly allowed into the
query cache. (This should not happen because UUID() is
non-deterministic.) (Bug#28897: http://bugs.mysql.com/28897)
* The Bytes_received and Bytes_sent status variables could hold
only 32-bit values (not 64-bit values) on some platforms.
* Passing a DECIMAL value as a parameter of a statement prepared
with PREPARE resulted in an error.
* For attempts to open a non-existent table, the server should
report ER_NO_SUCH_TABLE but sometimes reported
ER_TABLE_NOT_LOCKED. (Bug#27907: http://bugs.mysql.com/27907)
* Due to a race condition, executing FLUSH PRIVILEGES in one
thread could cause brief table unavailability in other
threads. (Bug#24988: http://bugs.mysql.com/24988)
* Conversion errors could occur when constructing the condition
for an IN predicate. The predicate was treated as if the
affected column contains NULL, but if the IN predicate is
inside NOT, incorrect results could be returned.
* Linux binaries were unable to dump core after executing a
setuid() call. (Bug#21723: http://bugs.mysql.com/21723)
* Using up-arrow for command-line recall in mysql* could cause a
segmentation fault. (Bug#10218: http://bugs.mysql.com/10218)
* Long pathnames for internal temporary tables could cause stack
overflows. (Bug#29015: http://bugs.mysql.com/29015)
* If a program binds a given number of parameters to a prepared
statement handle and then somehow changes stmt->param_count to
a different number, mysql_stmt_execute() could crash the
client or server. (Bug#28934: http://bugs.mysql.com/28934)
* Using a VIEW created with a non-existing DEFINER could lead to
incorrect results under some circumstances.
* An error occurred trying to connect to mysqld-debug.exe.
* Using an INTEGER column from a table to ROUND() a number
produced different results than using a constant with the same
value as the INTEGER column. (Bug# 28980)
* InnoDB tables using an indexed CHAR column with utf8 as the
default character set could fail to return the right rows.
* Using BETWEEN with non-indexed date columns and short formats
of the date string could return incorrect results.
* Granting access privileges to an individual table where the
database or table name contained an underscore would fail.
* A subquery with ORDER BY and LIMIT 1 could cause a server
crash. (Bug#28811: http://bugs.mysql.com/28811)
* Selecting GEOMETRY columns in a UNION caused a server crash.
* mysqltest used a too-large stack size on PPC/Debian Linux,
causing thread-creation failure for tests that use many
threads. (Bug#28333: http://bugs.mysql.com/28333)
* When constructing the path to the original .frm file, ALTER ..
RENAME was unnecessarily (and incorrectly) lowercasing the
entire path when not on a case-insensitive filesystem, causing
the statement to fail.
* PURGE MASTER LOGS BEFORE (subquery) caused a server crash.
Subqueries are forbidden in the BEFORE clause now.
* A server crash could happen under rare conditions such that a
temporary table outgrew heap memory reserved for it and the
remaining disk space was not big enough to store the table as
a MyISAM table. (Bug#28449: http://bugs.mysql.com/28449)
* On some Linux distributions where LinuxThreads and NPTL glibc
versions both are available, statically built binaries can
crash because the linker defaults to LinuxThreads when linking
statically, but calls to external libraries (such as libnss)
are resolved to NPTL versions. This cannot be worked around in
the code, so instead if a crash occurs on such a binary/OS
combination, print an error message that provides advice about
how to fix the problem.
* Stack overflow caused server crashes.
* The test case for mysqldump failed with bin-log disabled.
* Comparing a DATETIME column value with a user variable yielded
incorrect results. (Bug# 28261)
* Comparison of the string value of a date showed as unequal to
CURTIME(). Similar behavior was exhibited for DATETIME values.
* Implicit conversion of 9912101 to DATE did not match
CAST(9912101 AS DATE).
* The check-cpu script failed to detect AMD64 Turion processors
correctly. (Bug#17707: http://bugs.mysql.com/17707)
* After an upgrade, the names of stored routines referenced by
views were no longer displayed by SHOW CREATE VIEW. This was a
regression introduced by the fix for
* Killing from one connection a long-running EXPLAIN QUERY
started from another connection caused mysqld to crash.
* Subselects returning LONG values in MySQL versions later than
5.0.24a returned LONGLONG prior to this. The previous behavior
was restored. This issue was introduced by the fix for
* A buffer overflow could occur when using DECIMAL columns on
Windows operating systems.
* Executing EXPLAIN EXTENDED on a query using a derived table
over a grouping subselect could lead to a server crash. This
occurred only when materialization of the derived tables
required creation of an auxiliary temporary table, an example
being when a grouping operation was carried out with usage of
a temporary table. (Bug#28728: http://bugs.mysql.com/28728)
* Binary logging of prepared statements could produce
syntactically incorrect queries in the binary log, replacing
some parameters with variable names rather than variable
values. This could lead to incorrect results on replication
slaves. (Bug#12826: http://bugs.mysql.com/12826,
* Selecting MIN() on an indexed column that contained only NULL
values caused NULL to be returned for other result columns.
* mysql_upgrade failed if certain SQL modes were set. Now it
sets the mode itself to avoid this problem.
* Some test suite files were missing from some MySQL-test
packages. (Bug#26609: http://bugs.mysql.com/26609)
* When dumping procedures, mysqldump --compact generated output
that restored the session variable SQL_MODE without first
capturing it. When dumping routines, mysqldump --compact
neither set nor retrieved the value of SQL_MODE.
* Attempting to LOAD_FILE from an empty floppy drive under
Windows, caused the server to hang. For example, if you opened
a connection to the server and then issued the command SELECT
LOAD_FILE('a:test');, with no floppy in the drive, the server
was inaccessible until the modal pop-up dialog box was
dismissed. (Bug#28366: http://bugs.mysql.com/28366)
* mysqldump calculated the required memory for a hex-blob string
incorrectly causing a buffer overrun. This in turn caused
mysqldump to crash silently and produce incomplete output.
* The query SELECT '2007-01-01' + INTERVAL column_name DAY FROM
table_name caused mysqld to fail.
* The result of executing of a prepared statement created with
PREPARE s FROM "SELECT 1 LIMIT ?" was not replicated
correctly. (Bug#28464: http://bugs.mysql.com/28464)
* The second execution of a prepared statement from a UNION
query with ORDER BY RAND() caused the server to crash. This
problem could also occur when invoking a stored procedure
containing such a query.
* Trying to shut down the server following a failed LOAD DATA
INFILE caused mysqld to crash.
* Running CHECK TABLE concurrently with a SELECT, INSERT or
other statement on Windows could corrupt a MyISAM table.
* The error message for error number 137 did not report which
database/table combination reported the problem.
* Forcing the use of an index on a SELECT query when the index
had been disabled would raise an error without running the
query. The query now executes, with a warning generated noting
that the use of a disabled index has been ignored.
* Using CREATE TABLE LIKE ... would raise an assertion when
replicated to a slave.
* When using transactions and replication, shutting down the
master in the middle of a transaction would cause all slaves
to stop replicating. (Bug#22725: http://bugs.mysql.com/22725)
* Recreating a view that already exists on the master would
cause a replicating slave to terminate replication with a
'different error message on slave and master' error.
* CURDATE() is less than NOW(), either when comparing CURDATE()
directly (CURDATE() < NOW() is true) or when casting CURDATE()
to DATE (CAST(CURDATE() AS DATE) < NOW() is true). However,
storing CURDATE() in a DATE column and comparing col_name <
NOW() incorrectly yielded false. This is fixed by comparing a
DATE column as DATETIME for comparisons to a DATETIME
constant. (Bug#21103: http://bugs.mysql.com/21103)
* For dates with 4-digit year parts less than 200, an incorrect
implicit conversion to add a century was applied for date
arithmetic performed with DATE_ADD(), DATE_SUB(), + INTERVAL,
and - INTERVAL. (For example, DATE_ADD('0050-01-01 00:00:00',
INTERVAL 0 SECOND) became '2050-01-01 00:00:00'.)
* The result for CAST() when casting a value to UNSIGNED was
limited to the maximum signed BIGINT value, not the maximum
unsigned value. (Bug#8663: http://bugs.mysql.com/8663)
* A stored program that uses a variable name containing
multibyte characters could fail to execute.
* The BLACKHOLE storage engine does not support INSERT DELAYED
statements, but they were not being rejected.
* EXPLAIN for a query on an empty table immediately after its
creation could result in a server crash.
* Grouping queries with correlated subqueries in WHERE
conditions could produce incorrect results.
* libmysql.dll could not be dynamically loaded on Windows.
* Portability problems caused by use of isinf() were corrected.
* Using a TEXT local variable in a stored routine in an
expression such as SET var = SUBSTRING(var, 3) produced an
incorrect result. (Bug#27415: http://bugs.mysql.com/27415)
* A large filesort could result in a division by zero error and
a server crash. (Bug#27119: http://bugs.mysql.com/27119)
Bug fixes from 5.0.42 (Enterprise version):
* Security fix: Use of a view could allow a user to gain update
privileges for tables in other databases.
* Security fix: If a stored routine was declared using SQL
SECURITY INVOKER, a user who invoked the routine could gain
privileges. (Bug#27337: http://bugs.mysql.com/27337)
* Security fix: The requirement of the DROP privilege for RENAME
TABLE was not being enforced.
* NDB Cluster: Repeated insertion of data generated by mysqldump
into NDB tables could eventually lead to failure of the
cluster. (Bug#27437: http://bugs.mysql.com/27437)
* NDB Cluster: ndb_connectstring did not appear in the output of
SHOW VARIABLES. (Bug#26675: http://bugs.mysql.com/26675)
* NDB Cluster: INSERT IGNORE wrongly ignored NULL values in
unique indexes. (Bug#27980: http://bugs.mysql.com/27980)
* NDB Cluster: The name of the month "March" was given
incorrectly in the cluster error log.
* NDB Cluster (APIs): For BLOB reads on operations with lock
mode LM_CommittedRead, the lock mode was not upgraded to
LM_Read before the state of the BLOB had already been
calculated. The NDB API methods affected by this problem
included the following:
* NDB Cluster: The cluster waited 30 seconds instead of 30
milliseconds before reading table statistics.
* NDB Cluster: It was not possible to add a unique index to an
NDB table while in single user mode.
* The server could abort or deadlock for INSERT DELAYED
statements for which another insert was performed implicitly
(for example, via a stored function that inserted a row).
* The server could hang for INSERT IGNORE ... ON DUPLICATE KEY
UPDATE if an update failed.
* Quoted labels in stored routines were mishandled, rendering
the routines unusable.
* Changes to some system variables should invalidate statements
in the query cache, but invalidation did not happen.
* Flow control optimization in stored routines could cause
exception handlers to never return or execute incorrect logic.
* An attempt to execute CREATE TABLE ... SELECT when a temporary
table with the same name already existed led to the insertion
of data into the temporary table and creation of an empty
non-temporary table. (Bug#24508: http://bugs.mysql.com/24508)
* Concurrent execution of CREATE TABLE ... SELECT and other
statements involving the target table suffered from various
race conditions, some of which might have led to deadlocks.
* CREATE TABLE IF NOT EXISTS ... SELECT caused a server crash if
the target table already existed and had a BEFORE INSERT
trigger. (Bug#20903: http://bugs.mysql.com/20903)
* Deadlock occurred for attempts to execute CREATE TABLE IF NOT
EXISTS ... SELECT when LOCK TABLES had been used to acquire a
read lock on the target table.
* CAST() to DECIMAL did not check for overflow.
* Views ignored precision for CAST() operations.
* For InnoDB, in some rare cases the optimizer preferred a more
expensive ref access to a less expensive range access.
* A query with a NOT IN subquery predicate could cause a crash
when the left operand of the predicate evaluated to NULL.
* The fix for Bug#17212: http://bugs.mysql.com/17212 provided
correct sort order for misordered output of certain queries,
but caused significant overall query performance degradation.
(Results were correct (good), but returned much more slowly
(bad).) The fix also affected performance of queries for which
results were correct. The performance degradation has been
addressed. (Bug#27531: http://bugs.mysql.com/27531)
* For INSERT ... ON DUPLICATE KEY UPDATE statements that
affected many rows, updates could be applied to the wrong
rows. (Bug#27954: http://bugs.mysql.com/27954)
* Comparisons of DATE or DATETIME values for the IN() function
could yield incorrect results.
* LOAD DATA did not use CURRENT_TIMESTAMP as the default value
for a TIMESTAMP column for which no value was provided.
* SELECT COUNT(*) from a table containing a DATETIME NOT NULL
column could produce spurious warnings with the NO_ZERO_DATE
SQL mode enabled. (Bug#22824: http://bugs.mysql.com/22824)
* Nested aggregate functions could be improperly evaluated.
* Using CAST() to convert DATETIME values to numeric values did
not work. (Bug#23656: http://bugs.mysql.com/23656)
* Early NULL-filtering optimization did not work for eq_ref
table access. (Bug#27939: http://bugs.mysql.com/27939)
* Non-grouped columns were allowed by * in ONLY_FULL_GROUP_BY
SQL mode. (Bug#27874: http://bugs.mysql.com/27874)
* Debug builds on Windows generated false alarms about
uninitialized variables with some Visual Studio runtime
libraries. (Bug#27811: http://bugs.mysql.com/27811)
* mysqld did not check the length of option values and could
crash with a buffer overflow for long values.
* Index hints (USE INDEX, IGNORE INDEX, FORCE INDEX) cannot be
used with FULLTEXT indexes, but were not being ignored.
* mysql_upgrade did not detect failure of external commands that
it runs. (Bug#26639: http://bugs.mysql.com/26639)
* mysql_upgrade did not pass a password to mysqlcheck if one was
given. (Bug#25452: http://bugs.mysql.com/25452)
* On Windows, mysql_upgrade was sensitive to lettercase of the
names of some required components.
* The result set of a query that used WITH ROLLUP and DISTINCT
could lack some rollup rows (rows with NULL values for
grouping attributes) if the GROUP BY list contained constant
expressions. (Bug#24856: http://bugs.mysql.com/24856)
* Some upgrade problems are detected and better error messages
suggesting that mysql_upgrade be run are produced.
* A performance degradation was observed for outer join queries
to which a not-exists optimization was applied.
* SELECT * INTO OUTFILE ... FROM INFORMATION_SCHEMA.schemata
failed with an Access denied error, even for a user who has
the FILE privilege. (Bug#28181: http://bugs.mysql.com/28181)
* Certain queries that used uncorrelated scalar subqueries
caused EXPLAIN to to crash.
* INSERT...ON DUPLICATE KEY UPDATE could cause Error 1032: Can't
find record in ... for inserts into an InnoDB table unique
index using key column prefixes with an underlying utf8 string
column. (Bug#13191: http://bugs.mysql.com/13191)
* On Linux, the server could not create temporary tables if
lower_case_table_names was set to 1 and the value of tmpdir
was a directory name containing any uppercase letters.
* A slave that used --master-ssl-cipher could not connect to the
master. (Bug#21611: http://bugs.mysql.com/21611)
* mysqldump crashed if it got no data from SHOW CREATE PROCEDURE
(for example, when trying to dump a routine defined by a
different user and for which the current user had no
privileges). Now it prints a comment to indicate the problem.
It also returns an error, or continues if the --force option
is given. (Bug#27293: http://bugs.mysql.com/27293)
* Several math functions produced incorrect results for large
unsigned values. ROUND() produced incorrect results or a crash
for a large number-of-decimals argument.
* For storage engines that allow the current auto-increment
value to be set, using ALTER TABLE ... ENGINE to convert a
table from one such storage engine to another caused loss of
the current value. (For storage engines that do not support
setting the value, it cannot be retained anyway when changing
the storage engine.) (Bug#25262: http://bugs.mysql.com/25262)
* Comparison of a DATE with a DATETIME did not treat the DATE as
having a time part of 00:00:00.
* A multiple-table UPDATE could return an incorrect rows-matched
value if, during insertion of rows into a temporary table, the
table had to be converted from a MEMORY table to a MyISAM
table. (Bug#22364: http://bugs.mysql.com/22364)
* The omission of leading zeros in dates could lead to erroneous
results when these were compared with the output of certain
date and time functions.
* If CREATE TABLE t1 LIKE t2 failed due to a full disk, an empty
t2.frm file could be created but not removed. This file then
caused subsequent attempts to create a table named t2 to fail.
This is easily corrected at the filesystem level by removing
the t2.frm file manually, but now the server removes the file
if the create operation does not complete successfully.
* The MERGE storage engine could return incorrect results when
several index values that compare equality were present in an
index (for example, 'gross' and 'gross ', which are considered
equal but have different lengths).
* For InnoDB tables, a multiple-row INSERT of the form INSERT
INTO t (id...) VALUES (NULL...) ON DUPLICATE KEY UPDATE
id=VALUES(id), where id is an AUTO_INCREMENT column, could
cause ERROR 1062 (23000): Duplicate entry... errors or lost
rows. (Bug#27650: http://bugs.mysql.com/27650)
* mysql_install_db is supposed to detect existing system tables
and create only those that do not exist. Instead, it was
exiting with an error if tables already existed.
* Failure to allocate memory associated with
transaction_prealloc_size could cause a server crash.
* Aborting a statement on the master that applied to a
non-transactional statement broke replication. The statement
was written to the binary log but not completely executed on
the master. Slaves receiving the statement executed it
completely, resulting in loss of data synchrony. Now an error
code is written to the error log so that the slaves stop
without executing the aborted statement. (That is, replication
stops, but synchrony to the point of the stop is preserved and
you can investigate the problem.)
* The AUTO_INCREMENT value would not be correctly reported for
InnoDB tables when using SHOW CREATE TABLE statement or
mysqldump command. (Bug#23313: http://bugs.mysql.com/23313)
* Creating a temporary table with InnoDB when using the
one-file-per-table setting, when the host filesystem for
temporary tables is tmpfs would cause an assertion within
mysqld. This was due to the use of O_DIRECT when opening the
temporary table file. (Bug#26662: http://bugs.mysql.com/26662)
* An interaction between SHOW TABLE STATUS and other concurrent
statements that modify the table could result in a
divide-by-zero error and a server crash.
* mysqldump could not connect using SSL.
* yaSSL crashed on pre-Pentium Intel CPUs.
* Comparisons using row constructors could fail for rows
containing NULL values.
* Performing a UNION on two views that had had ORDER BY clauses
resulted in an Unknown column error.
* The CRC32() function returns an unsigned integer, but the
metadata was signed, which could cause certain queries to
return incorrect results. (For example, queries that selected
a CRC32() value and used that value in the GROUP BY clause.)
* A race condition between DROP TABLE and SHOW TABLE STATUS
could cause the latter to display incorrect information.
* mysqldump would not dump a view for which the DEFINER no
longer exists. (Bug#26817: http://bugs.mysql.com/26817)
* Changing a utf8 column in an InnoDB table to a shorter length
did not shorten the data values.
* Using SET GLOBAL to change the lc_time_names system variable
had no effect on new connections.
* The XML output representing an empty result was an empty
string rather than an empty <resultset/> element.
* mysqlbinlog produced different output with the -R option than
without it. (Bug#27171: http://bugs.mysql.com/27171)
* A stored function invocation in the WHERE clause was treated
as a constant. (Bug#27354: http://bugs.mysql.com/27354)
* For queries that used ORDER BY with InnoDB tables, if the
optimizer chose an index for accessing the table but found a
covering index that enabled the ORDER BY to be skipped, no
results were returned.
* Having the EXECUTE privilege for a routine in a database
should make it possible to USE that database, but the server
returned an error instead. This has been corrected. As a
result of the change, SHOW TABLES for a database in which you
have only the EXECUTE privilege returns an empty set rather
than an error. (Bug#9504: http://bugs.mysql.com/9504)
* Some views could not be created even when the user had the
requisite privileges. (Bug#24040: http://bugs.mysql.com/24040)
* Restoration of the default database after stored routine or
trigger execution on a slave could cause replication to stop
if the database no longer existed.
Daniel Fischer, Product Engineer +46 18174400 ext. 4537
MySQL GmbH, Radlkoferstr. 2, D-81373 Muenchen www.mysql.com
Geschaeftsfuehrer: Kaj Arnoe HRB Muenchen 162140
Are you MySQL certified? mysql.com/certification 49.011, 8.376
to post comments)