SEO

Dear MySQL users,

MySQL 6.0.4-alpha, a new version of the MySQL database system including
the Falcon transactional storage engine (now at beta stage), has been
released. The main page for MySQL 6.0 is at:

http://www.mysql.com/mysql60/

If you are new to the Falcon storage engine and need more information,
please read the Falcon Evaluation Guide at:

http://www.mysql.com/why-mysql/white...ng-started.php

and the Falcon White Paper at:

http://www.mysql.com/why-mysql/white...nes-falcon.php

MySQL 6.0.4-alpha is available in source and binary form for a number
of platforms from our download pages at

http://dev.mysql.com/downloads/mysql/6.0.html

and mirror sites. Note that not all mirror sites may be up to date at
this point in time, so if you can't find this version on some mirror,
please try again later or choose another download site.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches etc.:

http://forge.mysql.com/wiki/Contributing

Despite all trimming, describing all changes since the last released
version of MySQL 6.0 exceeds the mailing list configuration.
We had to split this message into two parts, this one (part 1) lists all
changes which are labeled "functionality", "security", "incompatible",
or "important".
You can view the full list online at

http://dev.mysql.com/doc/refman/6.0/en/news-6-0-4.html



"Functionality", "security", "incompatible", or "important" changes
since the last release:

Functionality added or changed:
* Important Change: Partitioning: Security Fix: It was possible,
by creating a partitioned table using the DATA DIRECTORY and
INDEX DIRECTORY options to gain privileges on other tables
having the same name as the partitioned table. As a result of
this fix, any table-level DATA DIRECTORY or INDEX DIRECTORY
options are now ignored for partitioned tables.
(Bug#32091: http://bugs.mysql.com/32091, CVE-2007-5970
(http://cve.mitre.org/cgi-bin/cvename...CVE-2007-5970))
See also Bug#29325: http://bugs.mysql.com/29325,
Bug#32111: http://bugs.mysql.com/32111
* Incompatible Change: The Unicode implementation has been
extended to provide support for supplementary characters that
lie outside the Basic Multilingual Plane (BMP). Noteworthy
features:
+ utf16 and utf32 character sets have been added. These correspond to
the UTF-16 and UTF-32 encodings of the Unicode character set, and
they both support supplementary characters.
+ The utf8 character set from previous versions of MySQL
has been renamed to utf8mb3, to reflect that its encoding
uses a maximum of three bytes for multi-byte characters.
(Old tables that previously used utf8 will be reported as
using utf8mb3 after an in-place upgrade to MySQL 6.0, but
otherwise work as before.)
+ The new utf8 character set in MySQL 6.0 is similar to
utf8mb3, but its encoding allows up to four bytes per
character to enable support for supplementary characters.
+ The ucs2 character set is essentially unchanged except
for the inclusion of some newer BMP characters.
In most respects, upgrading from MySQL 5.1 to 6.0 should
present few problems with regard to Unicode usage, although
there are some potential areas of incompatibility. Some
examples:
+ For the variable-length character data types (VARCHAR and
the TEXT types), the maximum length in characters for
utf8 columns is less in MySQL 6.0 than previously.
+ For all character data types (CHAR, VARCHAR, and the TEXT
types), the maximum number of characters for utf8 columns
that can be indexed is less in MySQL 6.0 than previously.
Consequently, if you want to upgrade tables from the old utf8
(now utf8mb3) to the current utf8, it may be necessary to
change some column or index definitions.
For additional details about the new Unicode character sets
and potential incompatibilities, see Section 9.1.8, "Unicode
Support," and Section 9.1.9, "Upgrading from Previous to
Current Unicode Support."
If you use events, a known issue is that if you upgrade from
MySQL 5.1 to 6.0.4, the event scheduler will not work, even
after you run mysql_upgrade. (This is an issue only for an
upgrade, not for a new installation of MySQL 6.0.4.) To work
around this upgrading problem, use these instructions:
1. In MySQL 5.1, before upgrading, create a dump file
containing your mysql.event table:
shell> mysqldump -uroot -p mysql event > event.sql
2. Stop the server, upgrade to MySQL 6.0, and start the server.
3. Recreate the mysql.event table using the dump file:
shell> mysql -uroot -p mysql < event.sql
4. Run mysql_upgrade to upgrade the other system tables in
the mysql database:
shell> mysql_upgrade -uroot -p
5. Restart the server. The event scheduler should run normally.
* Incompatible Change: Because of a change in the format of the
Falcon pages stored within Falcon database files, Falcon
databases created in MySQL 6.0.4 (or later) are not compatible
with previous releases, and existing Falcon databases are
incompatible with MySQL 6.0.4 (and later versions. You should
dump Falcon databases using mysqldump before upgrading, and
then reload them after the upgrade. For more information, see
Section 4.5.4, "mysqldump --- A Database Backup Program."
* Partitioning: Error messages for partitioning syntax errors
have been made more descriptive.
(Bug#29368: http://bugs.mysql.com/29368)
* Replication: Replication of the following now switches to row-based
logging in MIXED mode, and generates a warning in STATEMENT mode:
+ USER()
+ CURRENT_USER()
+ CURRENT_USER
+ FOUND_ROWS()
+ ROW_COUNT()
See Section 5.2.4.3, "Mixed Binary Logging (MBL) Format," for
more information. (Bug#12092: http://bugs.mysql.com/12092,
Bug#28086: http://bugs.mysql.com/28086,
Bug#30244: http://bugs.mysql.com/30244)
* Cluster Replication: A replication heartbeat mechanism has been added
to facilitate monitoring. This provides an alternative to checking log
files, making it possible to detect in real time when a slave has
failed. Configuration of heartbeats is done via a new
MASTER_HEARTBEAT_PERIOD = interval clause for the CHANGE MASTER TO
statement (see Section 12.6.2.1, "CHANGE MASTER TO Syntax");
monitoring can be done by checking the values of the status variables
Slave_heartbeat_period and Slave_received_heartbeats (see Section
5.1.5, "Status Variables").
The addition of replication heartbeats addresses a number of issues:
+ Relay logs were rotated every slave_net_timeout seconds
even if no statements were being replicated.
+ SHOW SLAVE STATUS displayed an incorrect value for
seconds_behind_master following a FLUSH LOGS statement.
+ Replication master-slave connections used
slave_net_timeout for connection timeouts.
(Bug#20435: http://bugs.mysql.com/20435,
Bug#29309: http://bugs.mysql.com/29309,
Bug#30932: http://bugs.mysql.com/30932)
* The --event-scheduler option without a value disabled the event
scheduler. Now it enables the event scheduler.
(Bug#31332: http://bugs.mysql.com/31332)
* mysqldump produces a -- Dump completed on DATE comment at the end of
the dump if --comments is given. The date causes dump files for
identical data taken at different times to appear to be different. The
new options --dump-date and --skip-dump-date control whether the date
is added to the comment. --skip-dump-date suppresses date printing.
The default is --dump-date (include the date in the comment).
(Bug#31077: http://bugs.mysql.com/31077)
* MySQL now can be compiled with gcc 4.2.x. There was a problem
involving a conflict with the min() and max() macros in
my_global.h. (Bug#28184: http://bugs.mysql.com/28184)
* 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: http://bugs.mysql.com/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.17, "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 filesystem 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. (Bug#19588: http://bugs.mysql.com/19588)
* Three options were added to mysqldump make it easier to generate a
dump from a slave server. --dump-slave is similar to --master-data,
but the CHANGE MASTER statement contains binary log coordinates for
the slave's master host, not the slave itself.
--apply-slave-statements causes STOP SLAVE and START SLAVE statements
to be added before the CHANGE MASTER statement and at the end of the
output, respectively. --include-master-host-port causes the CHANGE
MASTER statement to include MASTER_PORT and MASTER_HOST options for
the slave's master. (Bug#8368: http://bugs.mysql.com/8368)
* An alternative thread model is available for dealing with the issues
that occur with the original one-thread-per-client model when scaling
to large numbers of simultaneous connections. This model uses thread
pooling:
+ Connection manager threads do not dedicate a thread to each client
connection. Instead, the connection is added to the set of existing
connection sockets. The server collects input from these sockets and
when a complete request has been received from a given client, it is
queued for service.
+ The server maintains a pool of service threads to process requests.
When a queued request is waiting and there is an available (not
busy) service thread in the pool, the request is given to the thread
to be handled. After processing the request, the service thread
becomes available to process other requests.
Service threads are created at server startup and exist until the
server terminates. A given service thread is not tied to a specific
client connection and the requests that it processes over time may
originate from different client connections.
+ The pool of service threads has a fixed size, so the amount of
memory required for it does not increase as the number of client
connections increases.
For information about choosing one thread model over the other and
tuning the parameters that control thread resources, see Section
7.5.7, "How MySQL Uses Threads for Client Connections."
* When the server detects MyISAM table corruption, it now writes
additional information to the error log, such as the name and
line number of the source file, and the list of threads accessing
the table. Example: Got an error from thread_id=1, mi_dynrec.c:368.
This is useful information to include in bug reports.
* Two options relating to slow query logging have been added for mysqld.
--log-slow-slave-statements causes slow statements executed by a
replication slave to be written to the slow query log;
in_examined_row_limit can be used to cause queries which examine fewer
than the stated number of rows not to be logged.

Bugs fixed:
* Security Fix: Replication: It was possible for any connected user to
issue a BINLOG statement, which could be used to escalate privileges.
Use of the BINLOG statement now requires the SUPER privilege.
(Bug#31611: http://bugs.mysql.com/31611, CVE-2007-6313
(http://cve.mitre.org/cgi-bin/cvename...CVE-2007-6313))
* Security Fix: Three vulnerabilities in yaSSL versions 1.7.5 and
earlier were discovered that could lead to a server crash or execution
of unauthorized code. The exploit requires a server with yaSSL enabled
and TCP/IP connections enabled, but does not require valid MySQL
account credentials. The exploit does not apply to OpenSSL.
Note:
The proof-of-concept exploit is freely available on the Internet-
Everyone with a vulnerable MySQL configuration is advised to upgrade
immediately.
(Bug#33814: http://bugs.mysql.com/33814, CVE-2008-0226
(http://cve.mitre.org/cgi-bin/cvename...CVE-2008-0226),
CVE-2008-0227
(http://cve.mitre.org/cgi-bin/cvename...CVE-2008-0227))
* Security Fix: Using RENAME TABLE against a table with explicit DATA
DIRECTORY and INDEX DIRECTORY options can be used to overwrite system
table information by replacing the symbolic link points. the file to
which the symlink points. MySQL will now return an error when the file
to which the symlink points already exists.
(Bug#32111: http://bugs.mysql.com/32111, CVE-2007-5969
(http://cve.mitre.org/cgi-bin/cvename...CVE-2007-5969))
* Security Fix: ALTER VIEW retained the original DEFINER value,
even when altered by another user, which could allow that user
to gain the access rights of the view. Now ALTER VIEW is
allowed only to the original definer or users with the SUPER
privilege. (Bug#29908: http://bugs.mysql.com/29908)
* Security Fix: When using a FEDERATED table, the local server could be
forced to crash if the remote server returned a result with fewer
columns than expected. (Bug#29801: http://bugs.mysql.com/29801)
* Important Change: Incompatible Change: A number of problems
existed in the implementation of MERGE tables that could cause
problems. The problems are summarized below:
+ Bug#26379: http://bugs.mysql.com/26379 - Combination of
FLUSH TABLE and REPAIR TABLE corrupts a MERGE table. This
was caused in a number of situations:
1. A thread trying to lock a MERGE table performs busy waiting
while REPAIR TABLE or a similar table administration task
is ongoing on one or more of its MyISAM tables.
2. A thread trying to lock a MERGE table performs busy waiting
until all threads that did REPAIR TABLE or similar table
administration tasks on one or more of its MyISAM tables in
LOCK TABLES segments do UNLOCK TABLES. The difference against
problem #1 is that the busy waiting takes place after the
administration task. It is terminated by UNLOCK TABLES only.
3. Two FLUSH TABLES within a LOCK TABLES segment can invalidate
the lock. This does not require a MERGE table. The first
FLUSH TABLES can be replaced by any statement that requires
other threads to reopen the table. In 5.0 and 5.1 a single
FLUSH TABLES can provoke the problem.
+ Bug#26867: http://bugs.mysql.com/26867 - Simultaneously executing
LOCK TABLES and REPAIR TABLE on a MERGE table would result in
memory/cpu hogging.
Trying DML on a MERGE table, which has a child locked and repaired
by another thread, made an infinite loop in the server.
+ Bug#26377: http://bugs.mysql.com/26377 - Deadlock with
MERGE and FLUSH TABLE
Locking a MERGE table and its children in parent-child
order and flushing the child deadlocked the server.
+ Bug#25038: http://bugs.mysql.com/25038 - Waiting TRUNCATE
Truncating a MERGE child, while the MERGE table was in use, let the
truncate fail instead of waiting for the table to become free.
+ Bug#25700: http://bugs.mysql.com/25700 - MERGE base tables get
corrupted by OPTIMIZE/ANALYZE/REPAIR TABLE
Repairing a child of an open MERGE table corrupted the child. It was
necessary to FLUSH the child first.
+ Bug#30275: http://bugs.mysql.com/30275 - MERGE tables:
FLUSH TABLES or UNLOCK TABLES causes server to crash.
Flushing and optimizing locked MERGE children crashed the server.
+ Bug#19627: http://bugs.mysql.com/19627 - temporary merge
table locking
Use of a temporary MERGE table with non-temporary children could
corrupt the children. Temporary tables are never locked. Creation of
tables with non-temporary children of a temporary MERGE table is
now prohibited.
+ Bug#27660: http://bugs.mysql.com/27660 - Falcon: MERGE
table possible
It was possible to create a MERGE table with non-MyISAM children.
+ Bug#30273: http://bugs.mysql.com/30273 - MERGE tables:
Can't lock file (errno: 155)
This was a Windows-only bug. Table administration statements
sometimes failed with "Can't lock file (errno: 155)".
The fix introduces the following changes in behavior:
+ This patch changes the behavior of temporary MERGE tables. Temporary
MERGE must have temporary children. The old behavior was wrong. A
temporary table is not locked. Hence even non-temporary children
were not locked. See Bug#19627: http://bugs.mysql.com/19627.
+ You cannot change the union list of a non-temporary MERGE table
when LOCK TABLES is in effect. The following does not work:
CREATE TABLE m1 ... ENGINE=MRG_MYISAM ...;
LOCK TABLES t1 WRITE, t2 WRITE, m1 WRITE;
ALTER TABLE m1 ... UNION=(t1,t2) ...;
However, you can do this with a temporary MERGE table.
+ You cannot create a MERGE table with CREATE ... SELECT, neither as a
temporary MERGE table, nor as a non-temporary MERGE table. Example:
CREATE TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...;
gives error message: table is not BASE TABLE.
(Bug#19627: http://bugs.mysql.com/19627,
Bug#25038: http://bugs.mysql.com/25038,
Bug#25700: http://bugs.mysql.com/25700,
Bug#26377: http://bugs.mysql.com/26377,
Bug#26379: http://bugs.mysql.com/26379,
Bug#26867: http://bugs.mysql.com/26867,
Bug#27660: http://bugs.mysql.com/27660,
Bug#30275: http://bugs.mysql.com/30275,
Bug#30491: http://bugs.mysql.com/30491)
* Incompatible Change: SET PASSWORD statements now cause an implicit
commit, and thus are prohibited within stored functions and triggers.
(Bug#30904: http://bugs.mysql.com/30904)
* Incompatible Change: The mysql_install_db script could fail to locate
some components (including resolveip) during execution if the
--basedir option was specified on the command-line or within the
my.cnf file. This was due to a conflict when comparing the compiled-in
values and the supplied values. The --source-install command-line
option to the script has been removed and replaced with the --srcdir
option. mysql_install_db now locates components either using the
compiled-in options, the --basedir option or --srcdir option.
(Bug#30759: http://bugs.mysql.com/30759)
* Incompatible Change: It was possible for option files to be read twice
at program startup, if some of the standard option file locations
turned out to be the same directory. Now duplicates are removed from
the list of files to be read.
Also, users could not override system-wide settings using ~/.my.cnf
because SYSCONFDIR/my.cnf was read last. The latter file now is read
earlier so that ~/.my.cnf can override system-wide settings.
(Bug#20748: http://bugs.mysql.com/20748)
* Partitioning: Important Note: An apostrophe or single quote character
(') used in the DATA DIRECTORY, INDEX DIRECTORY, or COMMENT for a
PARTITION clause caused the server to crash. When used as part of a
CREATE TABLE statement, the crash was immediate. When used in an ALTER
TABLE statement, the crash did not occur until trying to perform a
SELECT or DML statement on the table. In either case, the server could
not be completely restarted until the .FRM file corresponding to the
newly created or altered table was deleted.
(Bug#30695: http://bugs.mysql.com/30695)


See part 2 for the description of further changes.


Enjoy,
Daniel

--
Daniel Fischer, Team Lead, Build +46 18174400 ext. 4537
MySQL GmbH, Dachauer Strasse 37, D-80335 Muenchen - www.mysql.com
Geschaeftsfuehrer: Kaj Arnoe HRB Muenchen 162140
Are you MySQL certified? mysql.com/certification 49.011, 8.376

Missing feature not mentioned...

Falcon works on PowerPC and UltraSparc.

Regards,
Antony

On 10 Mar, 2008, at 11:53, Joerg Bruehe wrote:

> Dear MySQL users,
>
> MySQL 6.0.4-alpha, a new version of the MySQL database system
> including
> the Falcon transactional storage engine (now at beta stage), has been
> released. The main page for MySQL 6.0 is at:
>
> http://www.mysql.com/mysql60/
>
> If you are new to the Falcon storage engine and need more information,
> please read the Falcon Evaluation Guide at:
>
> http://www.mysql.com/why-mysql/white...ng-started.php
>
> and the Falcon White Paper at:
>
> http://www.mysql.com/why-mysql/white...nes-falcon.php
>
> MySQL 6.0.4-alpha is available in source and binary form for a number
> of platforms from our download pages at
>
> http://dev.mysql.com/downloads/mysql/6.0.html
>
> and mirror sites. Note that not all mirror sites may be up to date at
> this point in time, so if you can't find this version on some mirror,
> please try again later or choose another download site.
>
> We welcome and appreciate your feedback, bug reports, bug fixes,
> patches etc.:
>
> http://forge.mysql.com/wiki/Contributing
>
> Despite all trimming, describing all changes since the last released
> version of MySQL 6.0 exceeds the mailing list configuration.
> We had to split this message into two parts, this one (part 1) lists
> all
> changes which are labeled "functionality", "security", "incompatible",
> or "important".
> You can view the full list online at
>
> http://dev.mysql.com/doc/refman/6.0/en/news-6-0-4.html
>
>
>
> "Functionality", "security", "incompatible", or "important" changes
> since the last release:
>
> Functionality added or changed:
> * Important Change: Partitioning: Security Fix: It was possible,
> by creating a partitioned table using the DATA DIRECTORY and
> INDEX DIRECTORY options to gain privileges on other tables
> having the same name as the partitioned table. As a result of
> this fix, any table-level DATA DIRECTORY or INDEX DIRECTORY
> options are now ignored for partitioned tables.
> (Bug#32091: http://bugs.mysql.com/32091, CVE-2007-5970
> (http://cve.mitre.org/cgi-bin/cvename...CVE-2007-5970))
> See also Bug#29325: http://bugs.mysql.com/29325,
> Bug#32111: http://bugs.mysql.com/32111
> * Incompatible Change: The Unicode implementation has been
> extended to provide support for supplementary characters that
> lie outside the Basic Multilingual Plane (BMP). Noteworthy
> features:
> + utf16 and utf32 character sets have been added. These correspond to
> the UTF-16 and UTF-32 encodings of the Unicode character set, and
> they both support supplementary characters.
> + The utf8 character set from previous versions of MySQL
> has been renamed to utf8mb3, to reflect that its encoding
> uses a maximum of three bytes for multi-byte characters.
> (Old tables that previously used utf8 will be reported as
> using utf8mb3 after an in-place upgrade to MySQL 6.0, but
> otherwise work as before.)
> + The new utf8 character set in MySQL 6.0 is similar to
> utf8mb3, but its encoding allows up to four bytes per
> character to enable support for supplementary characters.
> + The ucs2 character set is essentially unchanged except
> for the inclusion of some newer BMP characters.
> In most respects, upgrading from MySQL 5.1 to 6.0 should
> present few problems with regard to Unicode usage, although
> there are some potential areas of incompatibility. Some
> examples:
> + For the variable-length character data types (VARCHAR and
> the TEXT types), the maximum length in characters for
> utf8 columns is less in MySQL 6.0 than previously.
> + For all character data types (CHAR, VARCHAR, and the TEXT
> types), the maximum number of characters for utf8 columns
> that can be indexed is less in MySQL 6.0 than previously.
> Consequently, if you want to upgrade tables from the old utf8
> (now utf8mb3) to the current utf8, it may be necessary to
> change some column or index definitions.
> For additional details about the new Unicode character sets
> and potential incompatibilities, see Section 9.1.8, "Unicode
> Support," and Section 9.1.9, "Upgrading from Previous to
> Current Unicode Support."
> If you use events, a known issue is that if you upgrade from
> MySQL 5.1 to 6.0.4, the event scheduler will not work, even
> after you run mysql_upgrade. (This is an issue only for an
> upgrade, not for a new installation of MySQL 6.0.4.) To work
> around this upgrading problem, use these instructions:
> 1. In MySQL 5.1, before upgrading, create a dump file
> containing your mysql.event table:
> shell> mysqldump -uroot -p mysql event > event.sql
> 2. Stop the server, upgrade to MySQL 6.0, and start the server.
> 3. Recreate the mysql.event table using the dump file:
> shell> mysql -uroot -p mysql < event.sql
> 4. Run mysql_upgrade to upgrade the other system tables in
> the mysql database:
> shell> mysql_upgrade -uroot -p
> 5. Restart the server. The event scheduler should run normally.
> * Incompatible Change: Because of a change in the format of the
> Falcon pages stored within Falcon database files, Falcon
> databases created in MySQL 6.0.4 (or later) are not compatible
> with previous releases, and existing Falcon databases are
> incompatible with MySQL 6.0.4 (and later versions. You should
> dump Falcon databases using mysqldump before upgrading, and
> then reload them after the upgrade. For more information, see
> Section 4.5.4, "mysqldump --- A Database Backup Program."
> * Partitioning: Error messages for partitioning syntax errors
> have been made more descriptive.
> (Bug#29368: http://bugs.mysql.com/29368)
> * Replication: Replication of the following now switches to row-based
> logging in MIXED mode, and generates a warning in STATEMENT mode:
> + USER()
> + CURRENT_USER()
> + CURRENT_USER
> + FOUND_ROWS()
> + ROW_COUNT()
> See Section 5.2.4.3, "Mixed Binary Logging (MBL) Format," for
> more information. (Bug#12092: http://bugs.mysql.com/12092,
> Bug#28086: http://bugs.mysql.com/28086,
> Bug#30244: http://bugs.mysql.com/30244)
> * Cluster Replication: A replication heartbeat mechanism has been
> added
> to facilitate monitoring. This provides an alternative to checking log
> files, making it possible to detect in real time when a slave has
> failed. Configuration of heartbeats is done via a new
> MASTER_HEARTBEAT_PERIOD = interval clause for the CHANGE MASTER TO
> statement (see Section 12.6.2.1, "CHANGE MASTER TO Syntax");
> monitoring can be done by checking the values of the status variables
> Slave_heartbeat_period and Slave_received_heartbeats (see Section
> 5.1.5, "Status Variables").
> The addition of replication heartbeats addresses a number of issues:
> + Relay logs were rotated every slave_net_timeout seconds
> even if no statements were being replicated.
> + SHOW SLAVE STATUS displayed an incorrect value for
> seconds_behind_master following a FLUSH LOGS statement.
> + Replication master-slave connections used
> slave_net_timeout for connection timeouts.
> (Bug#20435: http://bugs.mysql.com/20435,
> Bug#29309: http://bugs.mysql.com/29309,
> Bug#30932: http://bugs.mysql.com/30932)
> * The --event-scheduler option without a value disabled the event
> scheduler. Now it enables the event scheduler.
> (Bug#31332: http://bugs.mysql.com/31332)
> * mysqldump produces a -- Dump completed on DATE comment at the end of
> the dump if --comments is given. The date causes dump files for
> identical data taken at different times to appear to be different. The
> new options --dump-date and --skip-dump-date control whether the date
> is added to the comment. --skip-dump-date suppresses date printing.
> The default is --dump-date (include the date in the comment).
> (Bug#31077: http://bugs.mysql.com/31077)
> * MySQL now can be compiled with gcc 4.2.x. There was a problem
> involving a conflict with the min() and max() macros in
> my_global.h. (Bug#28184: http://bugs.mysql.com/28184)
> * 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: http://bugs.mysql.com/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.17, "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 filesystem 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. (Bug#19588: http://bugs.mysql.com/19588)
> * Three options were added to mysqldump make it easier to generate a
> dump from a slave server. --dump-slave is similar to --master-data,
> but the CHANGE MASTER statement contains binary log coordinates for
> the slave's master host, not the slave itself.
> --apply-slave-statements causes STOP SLAVE and START SLAVE statements
> to be added before the CHANGE MASTER statement and at the end of the
> output, respectively. --include-master-host-port causes the CHANGE
> MASTER statement to include MASTER_PORT and MASTER_HOST options for
> the slave's master. (Bug#8368: http://bugs.mysql.com/8368)
> * An alternative thread model is available for dealing with the issues
> that occur with the original one-thread-per-client model when scaling
> to large numbers of simultaneous connections. This model uses thread
> pooling:
> + Connection manager threads do not dedicate a thread to each client
> connection. Instead, the connection is added to the set of existing
> connection sockets. The server collects input from these sockets and
> when a complete request has been received from a given client, it is
> queued for service.
> + The server maintains a pool of service threads to process requests.
> When a queued request is waiting and there is an available (not
> busy) service thread in the pool, the request is given to the thread
> to be handled. After processing the request, the service thread
> becomes available to process other requests.
> Service threads are created at server startup and exist until the
> server terminates. A given service thread is not tied to a specific
> client connection and the requests that it processes over time may
> originate from different client connections.
> + The pool of service threads has a fixed size, so the amount of
> memory required for it does not increase as the number of client
> connections increases.
> For information about choosing one thread model over the other and
> tuning the parameters that control thread resources, see Section
> 7.5.7, "How MySQL Uses Threads for Client Connections."
> * When the server detects MyISAM table corruption, it now writes
> additional information to the error log, such as the name and
> line number of the source file, and the list of threads accessing
> the table. Example: Got an error from thread_id=1, mi_dynrec.c:368.
> This is useful information to include in bug reports.
> * Two options relating to slow query logging have been added for
> mysqld.
> --log-slow-slave-statements causes slow statements executed by a
> replication slave to be written to the slow query log;
> in_examined_row_limit can be used to cause queries which examine fewer
> than the stated number of rows not to be logged.
>
> Bugs fixed:
> * Security Fix: Replication: It was possible for any connected user to
> issue a BINLOG statement, which could be used to escalate privileges.
> Use of the BINLOG statement now requires the SUPER privilege.
> (Bug#31611: http://bugs.mysql.com/31611, CVE-2007-6313
> (http://cve.mitre.org/cgi-bin/cvename...CVE-2007-6313))
> * Security Fix: Three vulnerabilities in yaSSL versions 1.7.5 and
> earlier were discovered that could lead to a server crash or execution
> of unauthorized code. The exploit requires a server with yaSSL enabled
> and TCP/IP connections enabled, but does not require valid MySQL
> account credentials. The exploit does not apply to OpenSSL.
> Note:
> The proof-of-concept exploit is freely available on the Internet-
> Everyone with a vulnerable MySQL configuration is advised to upgrade
> immediately.
> (Bug#33814: http://bugs.mysql.com/33814, CVE-2008-0226
> (http://cve.mitre.org/cgi-bin/cvename...CVE-2008-0226),
> CVE-2008-0227
> (http://cve.mitre.org/cgi-bin/cvename...CVE-2008-0227))
> * Security Fix: Using RENAME TABLE against a table with explicit DATA
> DIRECTORY and INDEX DIRECTORY options can be used to overwrite system
> table information by replacing the symbolic link points. the file to
> which the symlink points. MySQL will now return an error when the file
> to which the symlink points already exists.
> (Bug#32111: http://bugs.mysql.com/32111, CVE-2007-5969
> (http://cve.mitre.org/cgi-bin/cvename...CVE-2007-5969))
> * Security Fix: ALTER VIEW retained the original DEFINER value,
> even when altered by another user, which could allow that user
> to gain the access rights of the view. Now ALTER VIEW is
> allowed only to the original definer or users with the SUPER
> privilege. (Bug#29908: http://bugs.mysql.com/29908)
> * Security Fix: When using a FEDERATED table, the local server could
> be
> forced to crash if the remote server returned a result with fewer
> columns than expected. (Bug#29801: http://bugs.mysql.com/29801)
> * Important Change: Incompatible Change: A number of problems
> existed in the implementation of MERGE tables that could cause
> problems. The problems are summarized below:
> + Bug#26379: http://bugs.mysql.com/26379 - Combination of
> FLUSH TABLE and REPAIR TABLE corrupts a MERGE table. This
> was caused in a number of situations:
> 1. A thread trying to lock a MERGE table performs busy waiting
> while REPAIR TABLE or a similar table administration task
> is ongoing on one or more of its MyISAM tables.
> 2. A thread trying to lock a MERGE table performs busy waiting
> until all threads that did REPAIR TABLE or similar table
> administration tasks on one or more of its MyISAM tables in
> LOCK TABLES segments do UNLOCK TABLES. The difference against
> problem #1 is that the busy waiting takes place after the
> administration task. It is terminated by UNLOCK TABLES only.
> 3. Two FLUSH TABLES within a LOCK TABLES segment can invalidate
> the lock. This does not require a MERGE table. The first
> FLUSH TABLES can be replaced by any statement that requires
> other threads to reopen the table. In 5.0 and 5.1 a single
> FLUSH TABLES can provoke the problem.
> + Bug#26867: http://bugs.mysql.com/26867 - Simultaneously executing
> LOCK TABLES and REPAIR TABLE on a MERGE table would result in
> memory/cpu hogging.
> Trying DML on a MERGE table, which has a child locked and repaired
> by another thread, made an infinite loop in the server.
> + Bug#26377: http://bugs.mysql.com/26377 - Deadlock with
> MERGE and FLUSH TABLE
> Locking a MERGE table and its children in parent-child
> order and flushing the child deadlocked the server.
> + Bug#25038: http://bugs.mysql.com/25038 - Waiting TRUNCATE
> Truncating a MERGE child, while the MERGE table was in use, let the
> truncate fail instead of waiting for the table to become free.
> + Bug#25700: http://bugs.mysql.com/25700 - MERGE base tables get
> corrupted by OPTIMIZE/ANALYZE/REPAIR TABLE
> Repairing a child of an open MERGE table corrupted the child. It was
> necessary to FLUSH the child first.
> + Bug#30275: http://bugs.mysql.com/30275 - MERGE tables:
> FLUSH TABLES or UNLOCK TABLES causes server to crash.
> Flushing and optimizing locked MERGE children crashed the server.
> + Bug#19627: http://bugs.mysql.com/19627 - temporary merge
> table locking
> Use of a temporary MERGE table with non-temporary children could
> corrupt the children. Temporary tables are never locked. Creation of
> tables with non-temporary children of a temporary MERGE table is
> now prohibited.
> + Bug#27660: http://bugs.mysql.com/27660 - Falcon: MERGE
> table possible
> It was possible to create a MERGE table with non-MyISAM children.
> + Bug#30273: http://bugs.mysql.com/30273 - MERGE tables:
> Can't lock file (errno: 155)
> This was a Windows-only bug. Table administration statements
> sometimes failed with "Can't lock file (errno: 155)".
> The fix introduces the following changes in behavior:
> + This patch changes the behavior of temporary MERGE tables. Temporary
> MERGE must have temporary children. The old behavior was wrong. A
> temporary table is not locked. Hence even non-temporary children
> were not locked. See Bug#19627: http://bugs.mysql.com/19627.
> + You cannot change the union list of a non-temporary MERGE table
> when LOCK TABLES is in effect. The following does not work:
> CREATE TABLE m1 ... ENGINE=MRG_MYISAM ...;
> LOCK TABLES t1 WRITE, t2 WRITE, m1 WRITE;
> ALTER TABLE m1 ... UNION=(t1,t2) ...;
> However, you can do this with a temporary MERGE table.
> + You cannot create a MERGE table with CREATE ... SELECT, neither as a
> temporary MERGE table, nor as a non-temporary MERGE table. Example:
> CREATE TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...;
> gives error message: table is not BASE TABLE.
> (Bug#19627: http://bugs.mysql.com/19627,
> Bug#25038: http://bugs.mysql.com/25038,
> Bug#25700: http://bugs.mysql.com/25700,
> Bug#26377: http://bugs.mysql.com/26377,
> Bug#26379: http://bugs.mysql.com/26379,
> Bug#26867: http://bugs.mysql.com/26867,
> Bug#27660: http://bugs.mysql.com/27660,
> Bug#30275: http://bugs.mysql.com/30275,
> Bug#30491: http://bugs.mysql.com/30491)
> * Incompatible Change: SET PASSWORD statements now cause an implicit
> commit, and thus are prohibited within stored functions and triggers.
> (Bug#30904: http://bugs.mysql.com/30904)
> * Incompatible Change: The mysql_install_db script could fail to
> locate
> some components (including resolveip) during execution if the
> --basedir option was specified on the command-line or within the
> my.cnf file. This was due to a conflict when comparing the compiled-in
> values and the supplied values. The --source-install command-line
> option to the script has been removed and replaced with the --srcdir
> option. mysql_install_db now locates components either using the
> compiled-in options, the --basedir option or --srcdir option.
> (Bug#30759: http://bugs.mysql.com/30759)
> * Incompatible Change: It was possible for option files to be read
> twice
> at program startup, if some of the standard option file locations
> turned out to be the same directory. Now duplicates are removed from
> the list of files to be read.
> Also, users could not override system-wide settings using ~/.my.cnf
> because SYSCONFDIR/my.cnf was read last. The latter file now is read
> earlier so that ~/.my.cnf can override system-wide settings.
> (Bug#20748: http://bugs.mysql.com/20748)
> * Partitioning: Important Note: An apostrophe or single quote
> character
> (') used in the DATA DIRECTORY, INDEX DIRECTORY, or COMMENT for a
> PARTITION clause caused the server to crash. When used as part of a
> CREATE TABLE statement, the crash was immediate. When used in an ALTER
> TABLE statement, the crash did not occur until trying to perform a
> SELECT or DML statement on the table. In either case, the server could
> not be completely restarted until the .FRM file corresponding to the
> newly created or altered table was deleted.
> (Bug#30695: http://bugs.mysql.com/30695)
>
>
> See part 2 for the description of further changes.
>
>
> Enjoy,
> Daniel
>
> --
> Daniel Fischer, Team Lead, Build +46 18174400 ext. 4537
> MySQL GmbH, Dachauer Strasse 37, D-80335 Muenchen - www.mysql.com
> Geschaeftsfuehrer: Kaj Arnoe HRB Muenchen 162140
> Are you MySQL certified? mysql.com/certification 49.011, 8.376
>
>
>
>
>
> --
> MySQL Announce Mailing List
> For list archives: http://lists.mysql.com/announce
> To unsubscribe: http://lists.mysql.com/announce?
> unsub=annc@mysql.com
>