MySQL 4.1.19がリリースされました。


最も普及しているオープンソースデータベース管理システムであるMySQL 4.1.19がリリースされました。コミュニティエディションは、とミラーサイトのダウンロード・ページから、ソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。




このMySQL 4.1.19リリースは、最近報告されたMySQLクライアントーサーバプロトコルでのセキュリティ脆弱性対策のパッチを含んでいます。これらのセキュリティ脆弱性を発見し、報告して下さったStefano Di Paola氏(メールアドレスはstefano.dipaola@strippedです)に感謝申し上げます。




Functionality added or changed:

* Security enhancement: Added the global max_prepared_stmt_count
  system variable to limit the total number of prepared
  statements in the server. This limits the potential for
  denial-of-service attacks based on running the server out of
  memory by preparing huge numbers of statements. The current
  number of prepared statements is available through the
  prepared_stmt_count system variable.
* InnoDB now caches a list of unflushed files instead of
  scanning for unflushed files during a table flush operation.
  This improves performance when --innodb-file-per-table is set
  on a system with a large number of InnoDB tables.
* New charset command added to mysql command-line client. By
  typing charset name or \C name (such as \C UTF8), the client
  character set can be changed without reconnecting.
* Large file support was re-enabled for the MySQL server binary
  for the AIX 5.2 platform.
* When using the GROUP_CONCAT() function where the
  group_concat_max_len system variable was greater than 512, the
  type of the result was BLOB only if the query included an
  ORDER BY clause; otherwise the result was a VARCHAR.
  The result type of the GROUP_CONCAT() function is now VARCHAR
  only if the value of the group_concat_max_len system variable
  is less than or equal to 512. Otherwise, this function returns
  a BLOB. (Bug#14169:

Bugs fixed:

* Security fix: A malicious client, using specially crafted
  invalid login or COM_TABLE_DUMP packets was able to read
  uninitialized memory, which potentially, though unlikely in
  MySQL, could have led to an information disclosure. Thanks to
  Stefano Di Paola <stefano.dipaola@stripped> for finding and
  reporting this bug.
* NDB Cluster: A simultaneous DROP TABLE and table update
  operation utilising a table scan could trigger a node failure.
* NDB Cluster: Backups could fail for large clusters with many
  tables, where the number of tables approached MaxNoOfTables.
* The IN-to-EXISTS transformation was making a reference to a
  parse tree fragment that was left out of the parse tree. This
  caused problems with prepared statements.
* Attempting to set the default value of an ENUM or SET column
  to NULL caused a server crash.
* Index corruption could occur in cases when
  key_cache_block_size was not a multiple of myisam_block_size
  (for example, with key_cache_block_size=1536 and
* UNCOMPRESS(NULL) could cause subsequent UNCOMPRESS() calls to
  return NULL for legal non-NULL arguments.
* Conversion of a number to a CHAR UNICODE string returned an
  invalid result. (Bug#18691:
* A call to MIN() with a CASE expression as its argument could
  return a non-minimum value.
* A LOCK TABLES statement that failed could cause MyISAM not to
  update table statistics properly, causing a subsequent CHECK
  TABLE to report table corruption.
* Avoid trying to include <asm/atomic.h> when it doesn't work in
  C++ code. (Bug#13621:
* Executing SELECT on a large table that had been compressed
  within myisampack could cause a crash.
* NDB Cluster: In a 2-node cluster with a node failure,
  restarting the node with a low value for StartPartialTimeout
  could cause the cluster to come up partitioned ("split-brain"
  issue). (Bug#16447:
  A similar issue could occur when the cluster was first started
  with a sufficiently low value for this parameter.
* NDB Cluster: On systems with multiple network interfaces, data
  nodes would get "stuck" in startup phase 2 if the interface
  connecting them to the management server was working on node
  startup while the interface interconnecting the data nodes
  experienced a temporary outage.
* mysql_config returned incorrect libraries on x86_64 systems.
* mysql_reconnect() sent a SET NAMES statement to the server,
  even for pre-4.1 servers that do not understand the statement.
* During conversion from one character set to ucs2, multi-byte
  characters with no ucs2 equivalent were converted to multiple
  characters, rather than to 0x003F QUESTION MARK.
* The mysql_close() C API function leaked handles for
  share-memory connections on Windows.
* The euro sign (?) was not stored correctly in columns using
  the latin1_german1_ci or latin1_general_ci collation.
* The server was always built as though
  --with-extra-charsets=complex had been specified.
* SELECT ... WHERE column LIKE 'A%' when column had a key and
  used the latin2_czech_cs collation.
* A query using WHERE (column_1, column_2) IN ((value_1,
  value_2)[, (..., ...), ...]) would return incorrect results.
* The -lmtmalloc library was removed from the output of
  mysql_config on Solaris, as it caused problems when building
  DBD::mysql (and possibly other applications) on that platform
  that tried to use dlopen() to access the client library.
* When running a query that contained a GROUP_CONCAT( SELECT
  GROUP_CONCAT(...) ), the result was NULL except in the ROLLUP
  part of the result, if there was one.
* CASTdouble AS SIGNED INT) for large double values outside the
  signed integer range truncates the result to be within range,
  but the result sometimes had the wrong sign.
* SET value definitions containing commas were not rejected. Now
  a definition such as SET('a,b','c,d') results in an error.
* MyISAM: Keys for which the first part of the key was a CHAR or
  VARCHAR column using the UTF-8 character set and longer than
  254 bytes could become corrupted.
* NDB Cluster: A timeout in the handling of an ABORT condition
  with more that 32 operations could yield a node failure.
* NDB Cluster: A node restart immediately following a CREATE
  TABLE would fail. Important: This fix supports 2-node Clusters
  only. (Bug#18385:
* NDB Cluster: In event of a node failure during a rollback, a
  "false" lock could be established on the backup for that node,
  which lock could not be removed without restarting the node.
* NDB Cluster: The cluster created a crashed replica of a table
  having an ordered index --- or when logging was not enabled,
  of a table having a table or unique index --- leading to a
  crash of the cluster following 8 successibe restarts.
* NDB Cluster: When replacing a failed master node, the
  replacement node could cause the cluster to crash from a
  buffer overflow if it had an excessively large amount of data
  to write to the cluster log.
* NDB Cluster: Restarting nodes were allowed to start and join
  the cluster too early.
* If InnoDB encountered a HA_ERR_LOCK_TABLE_FULL error and
  rolled back a transaction, the transaction was still written
  to the binary log. (Bug#18283:
* Connecting to a server with a UCS2 default character set with
  a client using a non-UCS2 character set crashed the server.
* Character set conversion of string constants for UNION of
  constant and table column was not done when it was safe to do
  so. (Bug#15949:
* Use of TRUNCATE TABLE for a TEMPORARY table on a master server
  was propagated to slaves properly, but slaves did not
  decrement the Slave_open_temp_tables counter properly.
* SELECT COUNT(*) for a MyISAM table could return different
  results depending on whether an index was used.
* Large file support did not work in AIX server binaries.
* Security Improvement: GRANTs to users with wildcards in their
  host information could be erroneously applied to similar users
  with the same username and similar wildcards. For example, a
  privilege granted tofoo@%are also applied to userfoo@192.%.
* NDB Cluster: Inserting and deleting BLOB column values while a
  backup was in process could cause the loss of an ndbd node.
* Setting the myisam_repair_threads system variable to a value
  larger than 1 could cause corruption of large MyISAM tables.
* Security improvement: In grant table comparisons, improper use
  of a latin1 collation caused some hostname matches to be true
  that should have been false. Thanks to Deomid Ryabkov for
  finding this bug and proposing a solution.
* NDB Cluster: ndb_delete_all would run out of memory on tables
  containing BLOB columns.
* A statement containing GROUP BY and HAVING clauses could
  return incorrect results when the HAVING clause contained
  logic that returned FALSE for every row.
* mysqldump tried to dump data from a view. (In MySQL 4.1, this
  applies when connecting to a server from MySQL 5.0 or higher.)
* NDB Cluster: An UPDATE with an inner join failed to match any
  records if both tables in the join did not have a primary key.
* NDB Cluster: A DELETE with a join in the WHERE clause failed
  to retrieve any records if both tables in the join did not
  have a primary key. (Bug#17249:
* NDB Cluster: In some cases, LOAD DATA INFILE did not load all
  data into NDB tables. (Bug#17081:
* NDB Cluster: The REDO log would become corrupted (and thus
  unreadable) in some circumstances, due to a failure in the
  query handler. (Bug#17295:
* NDB Cluster: No error message was generated for setting
  NoOfFragmentLogFiles too low.
* NDB Cluster: No error message was generated for setting
  MaxNoOfAttributes too low.
* Binary distributions for Solaris contained files with group
  ownership set to the non-existing wheel group. Now the bin
  group is used. (Bug#15562:
* Killing a long-running query containing a subquery could cause
  a server crash. (Bug#14851:
* Repeated invocation of my_init() and my_end() caused
  corruption of character set data and connection failure.
* A FULLTEXT query in a prepared statement could result in
  unexpected behavior. (Bug#14496:
* A FULLTEXT query in a UNION could result in unexpected
  behavior. (Bug#16893:
* Server crash when dropping InnoDB constraints named
  TABLENAME_ibfk_0. (Bug#16387:
* Corrected race condition when dropping the adaptive hash index
  for a B-tree page in InnoDB.
* LOAD DATA FROM MASTER produced invalid warnings and Packet out
  of order errors when the database already existed on the
  slave. (Bug#15302:
* A key on a MEMORY table would sometimes fail to match a row.
* MYSQL_STMT objects were not preserved following a connection
  reset. Attempting to operate on them afterwards caused the
  server to crash. (Bug#12744: