MySQL 5.0.18 has been released
[Posted January 2, 2006 by corbet]
| From: |
| Joerg Bruehe <joerg-AT-mysql.com> |
| To: |
| announce-AT-lists.mysql.com, MySQL General List <mysql-AT-lists.mysql.com>,
packagers-AT-lists.mysql.com |
| Subject: |
| MySQL 5.0.18 has been released |
| Date: |
| Fri, 30 Dec 2005 18:05:14 +0100 |
Hi,
MySQL 5.0.18, a new version of the popular Open Source Database
Management System, has been released. The Community Edition is now
available in source and binary form for a number of platforms from our
download pages at
http://dev.mysql.com/downloads/
and mirror sites.
Note that not all mirror sites may be up to date at this point in time -
if you can't find this version on some mirror, please try again later or
choose another download site.
This is a bugfix version for the current production release family.
Please refer to our bug database at http://bugs.mysql.com/ for more
details about the individual bugs fixed in this version.
We welcome and appreciate your feedback!
News from the ChangeLog:
Functionality added or changed:
* It is now possible to build the server such that MyISAM tables can
support up to 128 keys rather than the standard 64. This can be
done by configuring the build using the option
--with-max-indexes=N,
where N<=128 is the maximum number of indexes to permit per table.
(Bug #10932 (http://bugs.mysql.com/10932))
* The server treats stored routine parameters and local variables
(and stored function return values) according to standard SQL.
Previously, parameters, variables, and return values were treated
as items in expressions and were subject to automatic (silent)
conversion and truncation. Now the data type is observed. Data type
conversion and overflow problems that occur in assignments result
in warnings, or errors in strict mode. The CHARACTER SET clause for
character data type declarations is used. Parameters, variables,
and return values must be scalars; it is no longer possible to
assign a row value. Also, stored functions execute using the
sql_mode value in force at function creation time rather than
ignoring it. For more information, see Section 17.2.1, "CREATE
PROCEDURE and CREATE FUNCTION."
(Bug #8702 (http://bugs.mysql.com/8702),
Bug #8768 (http://bugs.mysql.com/8768),
Bug #8769 (http://bugs.mysql.com/8769),
Bug #9078 (http://bugs.mysql.com/9078),
Bug #9572 (http://bugs.mysql.com/9572),
Bug #12903 (http://bugs.mysql.com/12903),
Bug #13705 (http://bugs.mysql.com/13705),
Bug #13808 (http://bugs.mysql.com/13808),
Bug #13909 (http://bugs.mysql.com/13909),
Bug #14161 (http://bugs.mysql.com/14161),
Bug #15148 (http://bugs.mysql.com/15148))
Bugs fixed:
* SHOW [FULL] COLUMNS and SHOW INDEX FROM did not function with
temporary tables.
(Bug #14271 (http://bugs.mysql.com/14271),
Bug #14387 (http://bugs.mysql.com/14387),
Bug #15224 (http://bugs.mysql.com/15224))
* The INFORMATION_SCHEMA.COLUMNS table did not report the size of
BINARY or VARBINARY columns.
(Bug #14271 (http://bugs.mysql.com/14271))
* The server would not compile under Cygwin.
(Bug #13640 (http://bugs.mysql.com/13640))
* DESCRIBE did not function with temporary tables.
(Bug #12770 (http://bugs.mysql.com/12770))
* Reversing the order of operands in a WHERE clause testing a simple
equality (such as WHERE t1.col1 = t2.col2) would produce different
output from EXPLAIN.
(Bug #15106 (http://bugs.mysql.com/15106))
* Column aliases were displayed incorrectly in a SELECT from a view
following an update to a base table of the view.
(Bug #14861 (http://bugs.mysql.com/14861))
* Prior versions did not allow the use of set functions which were
aggregated in an outer [sub]query, this did not comply with the
standard. Now this limitation is lifted. Moreover, the use of
nested set functions is now supported.
For more information, see a detailed comment in the bug database
entry. (Bug #12762 (http://bugs.mysql.com/12762))
* When a connection using yaSSL was aborted, the server would
continue to try to read the closed socket, and the thread continued
to appear in the output of SHOW PROCESSLIST. Note that this issue
did not affect secure connection attempts using OpenSSL.
(Bug #15772 (http://bugs.mysql.com/15772))
* InnoDB: Having two tables in a parent-child relationship enforced
by a foreign key where one table used ROW_FORMAT=COMPACT and the
other used ROW_FORMAT=REDUNDANT could result in a MySQL server
crash. Note that this problem did not exist prior to MySQL 5.0.3,
when the compact row format for InnoDB was introduced.
(Bug #15550 (http://bugs.mysql.com/15550))
* BDB: A DELETE, INSERT, or UPDATE of a BDB table could cause the
server to crash where the query contained a subquery using an index
read. (Bug #15536 (http://bugs.mysql.com/15536))
* A left join on a column that having a NULL value could cause the
server to crash. (Bug #15268 (http://bugs.mysql.com/15268))
* A replication slave server could sometimes crash on a BEFORE UPDATE
trigger if the UPDATE query was not executed in the same database
as the table with the trigger.
(Bug #14614 (http://bugs.mysql.com/14614))
* A race condition when creating temporary files caused a deadlock on
Windows with threads in Opening tables or Waiting for table states.
(Bug #12071 (http://bugs.mysql.com/12071))
* InnoDB: If FOREIGN_KEY_CHECKS was 0, InnoDB allowed inconsistent
foreign keys to be created.
(Bug #13778 (http://bugs.mysql.com/13778))
* NDB Cluster: Under some circumstances, it was possible for a
restarting node to undergo a forced shutdown.
(Bug #15632 (http://bugs.mysql.com/15632))
* NDB Cluster: If an abort by the Transaction Coordinator timed out,
the abort condition was incorrectly handled, causing the
transaction record to be released prematurely.
(Bug #15685 (http://bugs.mysql.com/15685))
* NDB Cluster: The ndb_read_multi_range.test script failed to drop a
table, causing the test to fail.
(Bug #15675 (http://bugs.mysql.com/15675))
(See also Bug #15401 (http://bugs.mysql.com/15401).)
* NDB Cluster: A node which failed during cluster startup was
sometimes not removed from the internal list of active nodes.
(Bug #15587 (http://bugs.mysql.com/15587))
* Resolution of the argument to the VALUES() function to a variable
inside a stored routine caused a server crash. The argument must be
a table column. (Bug #15441 (http://bugs.mysql.com/15441))
Enjoy!
Joerg
--
Joerg Bruehe, Senior Production Engineer
MySQL AB, www.mysql.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql@m.gmane.org