Skip navigation links
MySQL 5.0 Reference Manual :: C MySQL Change History :: C.1 Changes in Release 5.0.x (Production) :: C.1.24 Release Notes for MySQL Enterprise 5.0.70 [MRU] (27 September 2008)
C.1.25 Release Notes for MySQL Enterprise 5.0.68 [MRU] (13 August 2008) »
Section Navigation      [Toggle]

C.1.24. Release Notes for MySQL Enterprise 5.0.70 [MRU] (27 September 2008)

This is a Monthly Rapid Update release of the MySQL Enterprise Server 5.0.

This section documents all changes and bugfixes that have been applied since the last MySQL Enterprise Server release (5.0.68). If you would like to receive more fine-grained and personalized update alerts about fixes that are relevant to the version and features you use, please consider subscribing to MySQL Enterprise (a commercial MySQL offering). For more details please see http://www.mysql.com/products/enterprise/advisors.html.

Functionality added or changed:

  • Security Enhancement: To enable stricter control over the location from which user-defined functions can be loaded, the plugin_dir system variable has been backported from MySQL 5.1. If the value is nonempty, user-defined function object files can be loaded only from the directory named by this variable. If the value is empty, the behavior that is used prior to the inclusion of plugin_dir applies: The UDF object files must be located in a directory that is searched by your system's dynamic linker. (Bug#37428)

Bugs fixed:

  • Important Change: Security Fix: Additional corrections were made for the symlink-related privilege problem originally addressed in MySQL 5.0.60. The original fix did not correctly handle the data directory path name if it contained symlinked directories in its path, and the check was made only at table-creation time, not at table-opening time later. (Bug#32167, CVE-2008-2079)

    See also Bug#39277.

  • Incompatible Change: There were some problems using DllMain() hook functions on Windows that automatically do global and per-thread initialization for libmysqld.dll:

    • Per-thread initialization: MySQL internally counts the number of active threads, which causes a delay in my_end() if not all threads have exited. But there are threads that can be started either by Windows internally (often in TCP/IP scenarios) or by users. Those threads do not necessarily use libmysql.dll functionality but still contribute to the open-thread count. (One symptom is a five-second delay in times for PHP scripts to finish.)

    • Process-initialization: my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in the Windows loader.

    To correct these problems, DLL initialization code now is not invoked from libmysql.dll by default. To obtain the previous behavior (DLL initialization code will be called), set the LIBMYSQL_DLLINIT environment variable to any value. This variable exists only to prevent breakage of existing Windows-only applications that do not call mysql_thread_init() and work okay today. Use of LIBMYSQL_DLLINIT is discouraged and is removed in MySQL 6.0. (Bug#37226, Bug#33031)

  • For a TIMESTAMP column in an InnoDB table, testing the column with multiple conditions in the WHERE clause caused a server crash. (Bug#39353)

  • Queries of the form SELECT ... REGEXP BINARY NULL could lead to a hung or crashed server. (Bug#39021)

  • Statements of the form INSERT ... SELECT .. ON DUPLICATE KEY UPDATE col_name = DEFAULT could result in a server crash. (Bug#39002)

  • Repeated CREATE TABLE ... SELECT statements, where the created table contained an AUTO_INCREMENT column, could lead to an assertion failure. (Bug#38821)

  • A server crash or Valgrind warnings could result when a stored procedure selected from a view that referenced a function. (Bug#38291)

  • Incorrect handling of aggregate functions when loose index scan was used caused a server crash. (Bug#38195)

  • If a table has a BIT NOT NULL column c1 with a length shorter than 8 bits and some additional NOT NULL columns c2, ..., and a SELECT query has a WHERE clause of the form (c1 = constant) AND c2 ..., the query could return an unexpected result set. (Bug#37799)

  • The <=> operator could return incorrect results when comparing NULL to DATE, TIME, or DATETIME values. (Bug#37526)

  • For a MyISAM table with CHECKSUM = 1 and ROW_FORMAT = DYNAMIC table options, a data consistency check (maximum record length) could fail and cause the table to be marked as corrupted. (Bug#37310)

  • The max_length result set metadata value was calculated incorrectly under some circumstances. (Bug#37301)

  • The NO_BACKSLASH_ESCAPES SQL mode was ignored for LOAD DATA INFILE and SELECT INTO ... OUTFILE. The setting is taken into account now. (Bug#37114)

  • A query which had an ORDER BY DESC clause that is satisfied with a reverse range scan could cause a server crash for some specific CPU/compiler combinations. (Bug#36639)

  • Dumping information about locks in use by sending a SIGHUP signal to the server or by invoking the mysqladmin debug command could lead to a server crash in debug builds or to undefined behavior in production builds. (Bug#36579)

  • When the fractional part in a multiplication of DECIMAL values overflowed, the server truncated the first operand rather than the longest. Now the server truncates so as to produce more precise multiplications. (Bug#36270)

  • Changes to build files were made to enable the MySQL distribution to compile on Microsoft Visual C++ Express 2008. (Bug#33907)

  • mysqldump could fail to dump views containing a large number of columns. (Bug#31434)

  • Several MySQL programs could fail if the HOME environment variable had an empty value. (Bug#30394)

  • The BUILD/check-cpu build script failed if gcc had a different name (such as gcc.real on Debian). (Bug#27526)