This is a Monthly Rapid Update release of the MySQL Enterprise Server 5.0.
Bugs fixed:
Security Fix: A malformed password packet in the connection protocol could cause the server to crash. Thanks for Dormando for reporting this bug, and for providing details and a proof of concept. (Bug#28984, CVE-2007-3780)
Security Fix:
CREATE TABLE LIKE
did not require any
privileges on the source table. Now it requires the
SELECT
privilege.
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, Bug#25578, CVE-2007-3781)
Incompatible Change:
The names of stored functions referenced by views were not
properly displayed by SHOW CREATE
VIEW
.
The fix corrects a problem introduced by Bug#23491. There is an incompatibility when upgrading from versions affected by that bug fix (MySQL 5.0.40 through 5.0.43, MySQL 5.1.18 through 5.1.19): If you use mysqldump before upgrading from an affected version and reload the data after upgrading to a higher version, you must drop and recreate your views. (Bug#28605)
Incompatible Change:
When mysqldump was run with the
--delete-master-logs
option,
binary log files were deleted before it was known that the dump
had succeeded, not after. (The method for removing log files
used RESET MASTER
prior to the
dump. This also reset the binary log sequence numbering to
.000001
.) Now mysqldump
flushes the logs (which creates a new binary log number with the
next sequence number), performs the dump, and then uses
PURGE BINARY LOGS
to remove the
log files older than the new one. This also preserves log
numbering because the new log with the next number is generated
and only the preceding logs are removed. However, this may
affect applications if they rely on the log numbering sequence
being reset.
(Bug#24733)
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, Bug#28273)