MySQL 5.1.25rc版がリリースされました。

オリジナル版: http://dev.mysql.com/doc/refman/5.1/en/news-5-1-25.html

最も普及しているオープンソースデータベースの新たなリリース候補であるMySQL 5.1.25rc版がリリースされました。

MySQL 5.1.25rc版はまだ安定版候補のリリースであり、他の多くの試作商品リリースと同様、商品レベルのシステムまたは、重要なデータを含むシステムに対してインストールしないように注意してください。5.0使用の商品レベルのシステムについては、以下のMySQL Enterpriseの商品説明のページをご覧ください。


MySQL 5.1.25rc版は、http://dev.mysql.com/downloads/とミラーサイトのダウンロード・ページから、ソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。








News from the ChangeLog:

  Functionality added or changed:
    * Incompatible Change: A change has been made to the way that
      the server handles prepared statements. This affects prepared
      statements processed at the SQL level (using the PREPARE
      statement) and those processed using the binary client-server
      protocol (using the mysql_stmt_prepare() C API function).
      Previously, changes to metadata of tables or views referred to
      in a prepared statement could cause a server crash when the
      statement was next executed, or perhaps an error at execute
      time with a crash occurring later. For example, this could
      happen after dropping a table and recreating it with a
      different definition.
      Now metadata changes to tables or views referred to by
      prepared statements are detected and cause automatic
      repreparation of the statement when it is next executed.
      Metadata changes occur for DDL statements such as those that
      create, drop, alter, rename, or truncate tables, or that
      analyze, optimize, or repair tables. Repreparation also occurs
      after referenced tables or views are flushed from the table
      definition cache, either implicitly to make room for new
      entries in the cache, or explicitly due to FLUSH TABLES.
      Repreparation is automatic, but to the extent that it occurs,
      performance of prepared statements is diminished.
      Table content changes (for example, with INSERT or UPDATE) do
      not cause repreparation, nor do SELECT statements.
      An incompatibility with previous versions of MySQL is that a
      prepared statement may now return a different set of columns
      or different column types from one execution to the next. For
      example, if the prepared statement is SELECT * FROM t1,
      altering t1 to contain a different number of columns causes
      the next execution to return a number of columns different
      from the previous execution.
      Older versions of the client library cannot handle this change
      in behavior. For applications that use prepared statements
      with the new server, an upgrade to the new client library is
      strongly recommended.
      Along with this change to statement repreparation, the default
      value of the table_definition_cache system variable has been
      increased from 128 to 256. The purpose of this increase is to
      lessen the chance that prepared statements will need
      repreparation due to referred-to tables/views having been
      flushed from the cache to make room for new entries.
      A new status variable, Com_stmt_reprepare, has been introduced
      to track the number of repreparations.
      (Bug#27420: http://bugs.mysql.com/27420,
      Bug#27430: http://bugs.mysql.com/27430,
      Bug#27690: http://bugs.mysql.com/27690)
    * Important Change: Some changes were made to CHECK TABLE ...
      FOR UPGRADE and REPAIR TABLE with respect to detection and
      handling of tables with incompatible .frm files (files created
      with a different version of the MySQL server). These changes
      also affect mysqlcheck because that program uses CHECK TABLE
      and REPAIR table, and thus also mysql_upgrade because that
      program invokes mysqlcheck.
         + If your table was created by a different version of the
           MySQL server than the one you are currently running,
           CHECK TABLE ... FOR UPGRADE indicates that the table has
           an .frm file with an incompatible version. In this case,
           the result set returned by CHECK TABLE contains a line
           with a Msg_type value of error and a Msg_text value of
           Table upgrade required. Please do "REPAIR TABLE
           `tbl_name`" to fix it!
         + REPAIR TABLE without USE_FRM upgrades the .frm file to
           the current version.
         + If you use REPAIR TABLE ...USE_FRM and your table was
           created by a different version of the MySQL server than
           the one you are currently running, REPAIR TABLE will not
           attempt to repair the table. In this case, the result set
           returned by REPAIR TABLE contains a line with a Msg_type
           value of error and a Msg_text value of Failed repairing
           incompatible .FRM file.
           Previously, use of REPAIR TABLE ...USE_FRM with a table
           created by a different version of the MySQL server risked
           the loss of all rows in the table.
      (Bug#36055: http://bugs.mysql.com/36055)
    * mysql_upgrade now has a --tmpdir option to enable the location
      of temporary files to be specified.
      (Bug#36469: http://bugs.mysql.com/36469)

  Bugs fixed:
    * Important Change: The server no longer issues warnings for
      truncation of excess spaces for values inserted into CHAR
      columns. This reverts a change in the previous release that
      caused warnings to be issued.
      (Bug#30059: http://bugs.mysql.com/30059)
    * Replication: CREATE PROCEDURE and CREATE FUNCTION statements
      containing extended comments were not written to the binary
      log correctly, causing parse errors on the slave.
      (Bug#36570: http://bugs.mysql.com/36570)
      See also Bug#32575: http://bugs.mysql.com/32575
    * Replication: When flushing tables, there were a slight chance
      that the flush occurred between the processing of one table
      map event and the next. Since the tables were opened one by
      one, subsequent locking of tables would cause the slave to
      crash. This problem was observed when replicating NDBCLUSTER
      or InnoDB tables, when executing multi-table updates, and when
      a trigger or a stored routine performed an (additional) insert
      on a table so that two tables were effectively being inserted
      into in the same statement.
      (Bug#36197: http://bugs.mysql.com/36197)
    * Replication: CREATE VIEW statements containing extended
      comments were not written to the binary log correctly, causing
      parse errors on the slave. Now, all comments are stripped from
      such statements before being written to the binary log.
      (Bug#32575: http://bugs.mysql.com/32575)
      See also Bug#36570: http://bugs.mysql.com/36570
    * On WIndows 64-bit systems, temporary variables of long types
      were used to store ulong values, causing key cache
      initialization to receive distorted parameters. The effect was
      that setting key_buffer_size to values of 2GB or more caused
      memory exhaustion to due allocation of too much memory.
      (Bug#36705: http://bugs.mysql.com/36705)
    * Multiple-table UPDATE statements that used a temporary table
      could fail to update all qualifying rows or fail with a
      spurious duplicate-key error.
      (Bug#36676: http://bugs.mysql.com/36676)
    * A REGEXP match could return incorrect rows when the previous
      row matched the expression and used CONCAT() with an empty
      string. (Bug#36488: http://bugs.mysql.com/36488)
    * mysqltest ignored the value of --tmpdir in one place.
      (Bug#36465: http://bugs.mysql.com/36465)
    * When updating an existing instance (for example, from MySQL
      5.0 to 5.1, or 5.1 to 6.0), the Instance Configuration Wizard
      unnecessarily prompted for a root password when there was an
      existing root password.
      (Bug#36305: http://bugs.mysql.com/36305)
    * Conversion of a FLOAT ZEROFILL value to string could cause a
      server crash if the value was NULL.
      (Bug#36139: http://bugs.mysql.com/36139)
    * On Windows, the installer attempted to use JScript to
      determine whether the target data directory already existed.
      On Windows Vista x64, this resulted in an error because the
      installer was attempting to run the JScript in a 32-bit
      engine, which wasn't registered on Vista. The installer no
      longer uses JScript but instead relies on a native WiX
      command. (Bug#36103: http://bugs.mysql.com/36103)
    * mysqltest was performing escape processing for the
      --replace_result command, which it should not have been.
      (Bug#36041: http://bugs.mysql.com/36041)
    * An error in calculation of the precision of zero-length items
      (such as NULL) caused a server crash for queries that employed
      temporary tables. (Bug#36023: http://bugs.mysql.com/36023)
    * For EXPLAIN EXTENDED, execution of an uncorrelated IN subquery
      caused a crash if the subquery required a temporary table for
      its execution. (Bug#36011: http://bugs.mysql.com/36011)
    * The MERGE storage engine did a table scan for SELECT COUNT(*)
      statements when it could calculate the number of records from
      the underlying tables.
      (Bug#36006: http://bugs.mysql.com/36006)
    * The server crashed inside NOT IN subqueries with an impossible
      WHERE or HAVING clause, such as NOT IN (SELECT ... FROM t1,
      t2, ... WHERE 0). (Bug#36005: http://bugs.mysql.com/36005)
    * The Event Scheduler was not designed to work under the
      embedded server. It is now disabled for the embedded server,
      and the event_scheduler system variable is not displayed.
      (Bug#35997: http://bugs.mysql.com/35997)
    * Grouping or ordering of long values in unindexed BLOB or TEXT
      columns with the gbk or big5 character set crashed the server.
      (Bug#35993: http://bugs.mysql.com/35993)
    * SET GLOBAL debug='' resulted in a Valgrind warning in
      DbugParse(), which was reading beyond the end of the control
      string. (Bug#35986: http://bugs.mysql.com/35986)
    * The "prefer full scan on clustered primary key over full scan
      of any secondary key" optimizer rule introduced by
      Bug#26447: http://bugs.mysql.com/26447 caused a performance
      regression for some queries, so it has been disabled.
      (Bug#35850: http://bugs.mysql.com/35850)
    * The server ignored any covering index used for ref access of a
      table in a query with ORDER BY if this index was incompatible
      with the ORDER BY list and there was another covering index
      compatible with this list. As a result, suboptimal execution
      plans were chosen for some queries that used an ORDER BY
      clause. (Bug#35844: http://bugs.mysql.com/35844)
    * mysql_upgrade did not properly update the mysql.event table.
      (Bug#35824: http://bugs.mysql.com/35824)
    * An incorrect error and message was produced for attempts to
      create a MyISAM table with an index (.MYI) filename that was
      already in use by some other MyISAM table that was open at the
      same time. For example, this might happen if you use the same
      value of the INDEX DIRECTORY table option for tables belonging
      to different databases.
      (Bug#35733: http://bugs.mysql.com/35733)
    * Enabling the read_only system variable while autocommit mode
      was enabled caused SELECT statements for transactional storage
      engines to fail. (Bug#35732: http://bugs.mysql.com/35732)
    * The combination of GROUP_CONCAT(), DISTINCT, and LEFT JOIN
      could crash the server when the right table is empty.
      (Bug#35298: http://bugs.mysql.com/35298)
    * Some binaries produced stack corruption messages due to being
      built with versions of bison older than 2.1. Builds are now
      created using bison 2.3.
      (Bug#34926: http://bugs.mysql.com/34926)
    * On Windows 64-bit builds, an apparent compiler bug caused
      memory overruns for code in innobase/mem/*. Removed
      optimizations so as not to trigger this problem.
      (Bug#34297: http://bugs.mysql.com/34297)
    * Several additional configuration scripts in the BUILD
      directory now are included in source distributions. These may
      be useful for users who wish to build MySQL from source. (See
      Section 2.9.3, "Installing from the Development Source Tree,"
      for information about what they do.)
      (Bug#34291: http://bugs.mysql.com/34291)
    * Executing a FLUSH PRIVILEGES statement after creating a
      temporary table in the mysql database with the same name as
      one of the MySQL system tables caused the server to crash.
      Note: While it is possible to shadow a system table in this
      way, the temporary table exists only for the current user
      and connection, and does not effect any user privileges.
      (Bug#33275: http://bugs.mysql.com/33275)
    * Assignment of relative pathnames to general_log_file or
      slow_query_log_file did not always work.
      (Bug#32748: http://bugs.mysql.com/32748)
    * The mysql.servers table was not created during installation on
      Windows. (Bug#28680: http://bugs.mysql.com/28680,
      Bug#32797: http://bugs.mysql.com/32797)
    * The jp test suite was not working.
      (Bug#28563: http://bugs.mysql.com/28563)
    * The internal init_time() library function was renamed to
      my_init_time() to avoid conflicts with external libraries.
      (Bug#26294: http://bugs.mysql.com/26294)
    * The parser used signed rather than unsigned values in some
      cases that caused legal lengths in column declarations to be
      rejected. (Bug#15776: http://bugs.mysql.com/15776)