Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Jonathan Perkin (jperkinsun.com)
Date: Mon Jan 19 2009 - 11:27:53 CST
Dear MySQL users,
MySQL 6.0.9-alpha, a new version of the MySQL database system has been
released. The main page for MySQL 6.0 release is at
A new algorithm that uses both index access to the joined table and a join
buffer has been implemented. It's called Batched Key Access (BKA) Join
algorithm. The algorithm supports inner join, outer join and semi-join
operations, including nested outer joins and nested semi-joins. Block
Nested Loops Join algorithm previously used only for inner joins has been
amended and now can be employed for outer join and semi-join operations,
including nested nested outer joins and nested semi-joins.
MySQL 6.0 includes two new storage engines: the transactional Falcon
engine, and the crash-safe Maria engine.
If you are new to the Falcon storage engine and need more information,
please read the Falcon Evaluation Guide at
and the Falcon White Paper at
The Maria storage engine is a crash-safe version of MyISAM. Maria
supports all of the main functionality of the MyISAM engine, plus recovery
support (in the event of a system crash), all MyISAM row formats and a new
Maria-specific row format. Maria is documented at
MySQL 6.0.9-alpha is available in source and binary form for a number of
platforms 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.
We welcome and appreciate your feedback, bug reports, bug fixes, and
The following section lists changes since the previous version of MySQL
6.0. The full changelog can also be viewed online at
Jonathan Perkin, Product Engineering, MySQL
Database Technology Group, Sun Microsystems
Functionality added or changed:
* BACKUP DATABASE and RESTORE now indicate in the server's error
log which databases are being backed up or restored.
* Performance of SELECT * retrievals from
INFORMATION_SCHEMA.COLUMNS was improved slightly.
* Previously, index hints did not work for FULLTEXT searches.
Now they work as follows:
For natural language mode searches, index hints are silently
ignored. For example, IGNORE INDEX(i) is ignored with no
warning and the index is still used.
For boolean mode searches, index hints with FOR ORDER BY or
FOR GROUP BY are silently ignored. Index hints with FOR JOIN
or no FOR modifier are honored. In contrast to how hints apply
for non-FULLTEXT searches, the hint is used for all phases of
query execution (finding rows and retrieval, grouping, and
ordering). This is true even if the hint is given for a
non-FULLTEXT index. (Bug#38842: http://bugs.mysql.com/38842)
* MySQL support for adding collations using LDML specifications
did not support the <i> identity rule that indicates one
character sorts identically to another. The <i> rule now is
supported. (Bug#37129: http://bugs.mysql.com/37129)
* Previously, RESTORE overwrote any databases with information
from the backup image. Now, RESTORE aborts with an error if
the backup image contains any databases that currently exist
on the server, unless the optional keyword OVERWRITE is given
following the image filename.
* A new statement, PURGE BACKUP LOGS, enables the contents of
the MySQL Backup logs to be culled. See Section 126.96.36.199,
"PURGE BACKUP LOGS Syntax."
* Security Enhancement: When the DATA DIRECTORY or INDEX
DIRECTORY clause of a CREATE TABLE statement referred to a
subdirectory of the data directory via a symlinked component
of the data directory path, it was accepted, when for security
reasons it should be rejected.
* Incompatible Change: CHECK TABLE ... FOR UPGRADE did not check
for collation changes made in MySQL 6.0.1 to latin2_czech_cs
or collation changes made in MySQL 6.0.6 to big5_chinese_ci,
cp866_general_ci, gb2312_chinese_ci, and gbk_chinese_ci. (This
also affects mysqlcheck and mysql_upgrade, which cause that
statement to be executed.)
* Partitioning: Replication: Changing the transaction isolation
level while replicating partitioned InnoDB tables could cause
statement-based logging to fail.
* Partitioning: This bug was introduced in MySQL 6.0.5.
This regression was introduced by
* Partitioning: With READ COMMITTED transaction isolation level,
InnoDB uses a semi-consistent read that releases non-matching
rows after MySQL has evaluated the WHERE clause. However, this
was not happening if the table used partitions.
* Partitioning: A SELECT using a range WHERE condition with an
ORDER BY on a partitioned table caused a server crash.
* Partitioning: For a partitioned table having an AUTO_INCREMENT
column: If the first statement following a start of the server
or a FLUSH TABLES statement was an UPDATE statement, the
AUTO_INCREMENT column was not incremented correctly.
* Partitioning: The server attempted to execute the statements
ALTER TABLE ... ANALYZE PARTITION, ALTER TABLE ... CHECK
PARTITION, ALTER TABLE ... OPTIMIZE PARTITION, and ALTER TABLE
... REORGANIZE PARTITION on tables that were not partitioned.
See also Bug#20129: http://bugs.mysql.com/20129.
* Partitioning: The value of the CREATE_COLUMNS column in
INFORMATION_SCHEMA.TABLES was not partitioned for partitioned
tables. (Bug#38909: http://bugs.mysql.com/38909)
* Partitioning: When executing an ORDER BY query on a
partitioned InnoDB table using an index that was not in the
partition expression, the results were sorted on a
per-partition basis rather than for the table as a whole.
* Partitioning: Partitioned table checking sometimes returned a
warning with an error code of 0, making proper response to
errors impossible. The fix also renders the error message
subject to translation in non-English deployments.
* Partitioning: When SHOW CREATE TABLE was used on a partitioned
table, all of the table's PARTITION and SUBPARTITION clauses
were output on a single line, making it difficult to read or
parse. (Bug#14326: http://bugs.mysql.com/14326)
* Replication: Row-based replication failed with non-partitioned
MyISAM tables having no indexes.
* An assertion failure occurred for a join query when a small
size of the join buffer was set and the value of
record_per_key for the index used for a ref access with this
join buffer was big enough.
* Unique indexes on FALCON tables can not be created when the
the column is NOT NULL.
* Accessing user variables within triggers could cause a server
crash. (Bug#40770: http://bugs.mysql.com/40770)
* For single-table UPDATE statements, an assertion failure
resulted from a runtime error in a stored function (such as a
recursive function call or an attempt to update the same table
as in the UPDATE statement).
* Date values of 000-00-00 inserted into a FALCON table were
incorrectly recognized and returned when performing a SELECT
on a field with an index.
* Several MySQL Backup-related memory-use issues identified by
Valgrind were corrected.
* When executing concurrent CREATE TABLE ... SELECT statements
on a Maria table, the error Error: Memory allocated at
trnman.c:129 was underrun, discovered at ma_close.c:65 error
would be logged in the error file, and the server would
eventually crash. (Bug#40416: http://bugs.mysql.com/40416)
* Prepared statements allowed invalid dates to be inserted when
the ALLOW_INVALID_DATES SQL mode was not enabled.
* With statement-based binary logging format and a transaction
isolation level of READ COMMITTED or stricter, InnoDB printed
an error because statement-based logging might lead to
inconsistency between master and slave databases. However,
this error was printed even when binary logging was not
enabled (in which case, no such inconsistency can occur).
* A query with an outer join where the ON expression evaluated
to the constant FALSE could return incorrect results when a
join buffer was used for the outer join operation.
* Errors from a BACKUP DATABASE or RESTORE operation were shown
by SHOW WARNINGS as warnings, not errors.
* If several errors occurred during a BACKUP DATABASE or RESTORE
operation, the final error was returned to the client, even
though the first error is usually more pertinent.
* Creation of a tablespace file within FALCON could create a
tablespace entry in the
INFORMATION_SCHEMA.FALCON_TABLESPACE_IO even the underlying
data file had not been created.
* Specifying the --log-backup-output option without an argument
set the destination for the backup logs to FILE rather than to
the default of TABLE. (Bug#40282: http://bugs.mysql.com/40282)
* mc.exe is no longer needed to compile MySQL on Windows. This
makes it possible to build MySQL from source using Visual
Studio Express 2008. (Bug#40280: http://bugs.mysql.com/40280)
* The server could generate extra rows in the result set for a
query with a nested outer join if the inner tables of the
outer join were joined using join buffers.
* If BACKUP DATABASE was used to back up an empty database and
binary logging enabled, the backup image was flagged as
containing binary log information even though it did not.
Using RESTORE with the backup image then crashed trying to
parse the binary log filename.
* The backup_history_log_file and backup_progress_log_file
system variables were not settable at server startup. Now they
are. (Bug#40219: http://bugs.mysql.com/40219)
* The default value of the backup_history_log and
backup_progress_log system variables is ON, but explicitly
setting them to DEFAULT set them to OFF.
* When an outer join employed a join buffer to join the first
inner table by the Blocked Nested Loops algorithm, extra
NULL-complemented rows could be generated if the WHERE clause
contained conditions that can be pushed down to this table.
* When the optimizer joined an inner table of an outer join
using both "not exists" optimization and a join buffer, an
incorrect result set could be returned.
* Support for the revision field in .frm files has been removed.
This addresses the downgrading problem introduced by the fix
for Bug#17823: http://bugs.mysql.com/17823.
* The MySQL Backup message logger caused an assertion failure.
* Retrieval speed from the following INFORMATION_SCHEMA tables
was improved by shortening the VARIABLE_VALUE column to 1024
characters: GLOBAL_VARIABLES, SESSION_VARIABLES,
GLOBAL_STATUS, and SESSION_STATUS.
As a result of this change, any variable value longer than
1024 characters will be truncated with a warning. This affects
only the init_connect system variable.
* If the operating system is configured to return leap seconds
from OS time calls or if the MySQL server uses a time zone
definition that has leap seconds, functions such as NOW()
could return a value having a time part that ends with :59:60
or :59:61. If such values are inserted into a table, they
would be dumped as is by mysqldump but considered invalid when
reloaded, leading to backup/restore problems.
Now leap second values are returned with a time part that ends
with :59:59. This means that a function such as NOW() can
return the same value for two or three consecutive seconds
during the leap second. It remains true that literal temporal
values having a time part that ends with :59:60 or :59:61 are
For additional details about leap-second handling, see Section
9.7.2, "Time Zone Leap Second Support."
* The server could crash during a sort-order optimization of a
dependent subquery. (Bug#39844: http://bugs.mysql.com/39844)
* Recovery of a tablespace for FALCON tables could fail if the
tablespace was already in use.
* Creating a FALCON table while specifying a specific tablespace
and partition to be used for the table will fail if the
specified tablespace does not already exist, returning a error
indicating general table creation failure. The message has
been updated to indicate that the failure is due to
* With the ONLY_FULL_GROUP_BY SQL mode enabled, the check for
non-aggregated columns in queries with aggregate functions,
but without a GROUP BY clause was treating all the parts of
the query as if they were in the select list. This is fixed by
ignoring the non-aggregated columns in the WHERE clause.
* Concurrent execution of BACKUP DATABASE and DML operations on
MyISAM tables could produce a deadlock.
* CHECK TABLE failed for MyISAM INFORMATION_SCHEMA tables.
* On 64-bit Windows systems, the server accepted key_buffer_size
values larger than 4GB, but allocated less. (For example,
specifying a value of 5GB resulted in 1GB being allocated.)
* Compiling MySQL with FALCON support enabled with a compiler
that does not support exceptions would fail to complete
successfully. configure has been updated to switch off FALCON
support if the specified compiler does not support exceptions.
* Use of the PACK_KEYS or MAX_ROWS table option in ALTER TABLE
should have triggered table reconstruction but did not.
* The server returned a column type of VARBINARY rather than
DATE as the result from the COALESCE(), IFNULL(), IF(),
GREATEST(), or LEAST() functions or CASE expression if the
result was obtained using filesort in an anonymous temporary
table during the query execution.
* Starting MySQL with FALCON support when MySQL has not been
compiled with a compiler supporting exceptions would lead to
strange errors and results. MySQL will now fail to initialize
if you have compiled without exceptions enabled with the
following message: 081116 12:21:12 [ERROR] Falcon must be
compiled with C++ exceptions enabled to work. Please adjust
your compile flags. [Falcon] Error: Falcon exiting process
* A server built using yaSSL for SSL support would crash if
configured to use an RSA key and a client sent a cipher list
containing a non-RSA key as acceptable.
* When built with Valgrind, the server failed to access tables
created with the DATA DIRECTORY or INDEX DIRECTORY table
option. (Bug#39102: http://bugs.mysql.com/39102)
* With binary logging enabled CREATE VIEW was subject to
possible buffer overwrite and a server crash.
* The fast mutex implementation was subject to excessive lock
contention. (Bug#38941: http://bugs.mysql.com/38941)
* Use of InnoDB monitoring (SHOW ENGINE INNODB STATUS or one of
the InnoDB Monitor tables) could cause a server crash due to
invalid access to a shared variable in a concurrent
environment. (Bug#38883: http://bugs.mysql.com/38883)
* Column names constructed due to wild-card expansion done
inside a stored procedure could point to freed memory if the
expansion was performed after the first call to the stored
procedure. (Bug#38823: http://bugs.mysql.com/38823)
* If delayed insert failed to upgrade the lock, it did not free
the temporary memory storage used to keep newly constructed
BLOB values in memory, resulting in a memory leak.
* The server unnecessarily acquired a query cache mutex even
with the query cache disabled, resulting in a small
* On Windows, a five-second delay occurred at shutdown of
applications that used the embedded server.
* On Solaris, a scheduling policy applied to the main server
process could be unintentionally overwritten in
* BACKUP DATABASE failed to use the native driver for a Falcon
table if the table was partitioned.
* On Windows, the embedded server would crash in
mysql_library_init() if the language file was missing.
* The Event Scheduler no longer logs "started in thread" or
"executed" successfully messages to the error log.
* Setting the debug system variable and executing a SELECT
statement resulted in a Valgrind warning.
* An incorrectly checked XOR subquery optimization resulted in
an assertion failure. (Bug#37899: http://bugs.mysql.com/37899)
* A SELECT with a NULL NOT IN condition containing a complex
subquery from the same table as in the outer select caused an
assertion failure. (Bug#37894: http://bugs.mysql.com/37894)
* Use of an uninitialized constant in EXPLAIN evaluation caused
an assertion failure. (Bug#37870: http://bugs.mysql.com/37870)
* A query that could use one index to produce the desired
ordering and another index for range access with index
condition pushdown could cause a server crash.
* Renaming an ARCHIVE table to the same name with different
lettercase and then selecting from it could cause a server
crash. (Bug#37719: http://bugs.mysql.com/37719)
* For queries executed with the batched-key access method, an
incorrect value of an internal parameter caused a server
crashe if join_buffer_size was less then 256.
* Compiling MySQL with FALCON support enabled on Solaris 9 using
the Sun Studio compiler would fail with error: "Interlock.h",
line 149: Error: #error cas not defined. We need>= Solaris 10.
* TIMEDIFF() was erroneously treated as always returning a
positive result. Also, CAST() of TIME values to DECIMAL
dropped the sign of negative values.
* mysqlcheck used SHOW FULL TABLES to get the list of tables in
a database. For some problems, such as an empty .frm file for
a table, this would fail and mysqlcheck then would neglect to
check other tables in the database.
* Updating a view with a subquery in the CHECK option could
cause an assertion failure.
* Statements that displayed the value of system variables (for
example, SHOW VARIABLES) expect variable values to be encoded
in character_set_system. However, variables set from the
command line such as basedir or datadir were encoded using
character_set_filesystem and not converted correctly.
* On a 32-bit server built without big tables support, the
offset argument in a LIMIT clause might be truncated due to a
64-bit to 32-bit cast.
* Specifying a database name twice to BACKUP DATABASE caused a
server crash. Now BACKUP DATABASE ignores duplicate names.
* If a non-directory file f without an extension was created in
the data directory, the server would allow clients to execute
a USE f statement even though f could not be a database. The
server now verifies that that the named database corresponds
to a directory. (Bug#36897: http://bugs.mysql.com/36897)
* The FALCON storage would silently recreate missing tablespace
files if they did not exist. Errors are now written to the
MySQL error log when the FALCON system tablespace files are
found to be missing. Warnings are produce in the log file when
attempting to access data tablespace files that do not exist.
* Use of CONVERT() with GROUP BY to convert numeric values to
CHAR could return truncated results.
* The mysql client, when built with Visual Studio 2005, did not
display Japanese characters.
* Setting the slave_compressed_protocol system variable to
DEFAULT failed in the embedded server.
* Processing for NULL-complemented rows in the result sets of
queries with nested outer joins could be incorrect.
* The columns that store character set and collation names in
several INFORMATION_SCHEMA tables were lengthened because they
were not long enough to store some possible values: SCHEMATA,
TABLES, COLUMNS, CHARACTER_SETS, COLLATIONS, and
* Queries executed using the batched-key access method could
cause an assertion fail when key expressions for a ref access
depended on columns not only from the previous join table.
* Selecting from an INFORMATION_SCHEMA table into an incorrectly
defined MERGE table caused an assertion failure.
* perror on Windows did not know about Win32 system error codes.
* EXPLAIN EXTENDED evaluation of aggregate functions that
required a temporary table caused a server crash.
* BACKUP DATABASE produced an incorrect error message when the
backup image filename contained a non-existent directory.
* SHOW GLOBAL STATUS shows values that aggregate the session
status values for all threads. This did not work correctly for
the embedded server. (Bug#34517: http://bugs.mysql.com/34517)
* There were spurious warnings about "Truncated incorrect DOUBLE
value" in queries with MATCH ... AGAINST and > or < with a
constant (which was reported as an incorrect DOUBLE value) in
the WHERE condition. (Bug#34374: http://bugs.mysql.com/34374)
* mysqldumpslow did not aggregate times.
* mysql_config did not output -ldl (or equivalent) when needed
for --libmysqld-libs, so its output could be insufficient to
build applications that use the embedded server.
* For a stored procedure containing a SELECT * ... RIGHT JOIN
query, execution failed for the second call.
* The ROUTINES.DATA_TYPE,
REFERENTIAL_CONSTRAINTS.DATA_TYPE columns were declared longer
than the maximum allowed identifier length.
* If a TEMPORARY table existed with the same name as a regular
table, BACKUP DATABASE saved the temporary table, causing a
subsequent RESTORE to fail.
* Previously, use of index hints with views (which do not have
indexes) produced the error ERROR 1221 (HY000): Incorrect
usage of USE/IGNORE INDEX and VIEW. Now this produces ERROR
1176 (HY000): Key '...' doesn't exist in table '...', the same
error as for base tables without an appropriate index.
* Execution of a prepared statement that referred to a system
variable caused a server crash.
* Some division operations produced a result with incorrect
precision. (Bug#31616: http://bugs.mysql.com/31616)
* Server variables could not be set to their current values on
Linux platforms. (These fixes are in addition to those made in
MySQL 6.0.5.) (Bug#31177: http://bugs.mysql.com/31177)
See also Bug#6958: http://bugs.mysql.com/6958.
* Searching for text values on a column using a character set
that provides multi-weight characters and sequences on an
INNODB or FALCON table with an index would fail to find the
expanded value. (Bug#29246: http://bugs.mysql.com/29246)
* Some SHOW statements and retrievals from the
INFORMATION_SCHEMA TRIGGERS and EVENTS tables used a temporary
table and incremented the Created_tmp_disk_tables status
variable, due to the way that TEXT columns are handled. The
TRIGGERS.SQL_MODE, TRIGGERS.DEFINER, and EVENTS.SQL_MODE
columns now are VARCHAR to avoid this problem.
* XA transaction rollbacks could result in corrupted transaction
states and a server crash.
* There were cases where string-to-number conversions would
produce warnings for CHAR values but not for VARCHAR values.
* For several read only system variables that were viewable with
SHOW VARIABLES, attempting to view them with SELECT var_name
or set their values with SET resulted in an unknown system
variable error. Now they can be viewed with SELECT var_name
and attempting to set their values results in a message
indicating that they are read only.
* ALTER TABLE for an ENUM column could change column values.
* Setting the session value of the max_allowed_packet or
net_buffer_length system variable was allowed but had no
effect. The session value of these variables is now read only.
* A race condition between the mysqld.exe server and the Windows
service manager could lead to inability to stop the server
from the service manager.
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql