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
>