Skip navigation links
C.1.25 Changes in MySQL 5.1.27 (Not released) »
Section Navigation      [Toggle]

C.1.24. Changes in MySQL 5.1.28 (28 August 2008)

Functionality added or changed:

Bugs fixed:

  • Performance: Incompatible Change: Some performance problems of SHOW ENGINE INNODB STATUS were reduced by removing used cells and Total number of lock structs in row lock hash table from the output. Now these values are present only if the UNIV_DEBUG symbol is defined at MySQL build time. (Bug#36941, Bug#36942)

  • Performance: Over-aggressive lock acquisition by InnoDB when calculating free space for tablespaces could result in performance degradation when multiple threads were executing statements on multi-core machines. (Bug#38185)

  • Important Change: Security Fix: Additional corrections were made for the symlink-related privilege problem originally addressed in MySQL 5.1.24. 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.

    Note

    Additional fixes were made in MySQL 5.1.41.

    (Bug#32167, CVE-2008-2079)

    See also Bug#39277.

  • Security Enhancement: The server consumed excess memory while parsing statements with hundreds or thousands of nested boolean conditions (such as OR (OR ... (OR ... ))). This could lead to a server crash or incorrect statement execution, or cause other client statements to fail due to lack of memory. The latter result constitutes a denial of service. (Bug#38296)

  • 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)

  • Incompatible Change: SHOW STATUS took a lot of CPU time for calculating the value of the Innodb_buffer_pool_pages_latched status variable. Now this variable is calculated and included in the output of SHOW STATUS only if the UNIV_DEBUG symbol is defined at MySQL build time. (Bug#36600)

  • Incompatible Change: An additional correction to the original MySQL 5.1.23 fix was made to normalize directory names before adding them to the list of directories. This prevents /etc/ and /etc from being considered different, for example. (Bug#20748)

    See also Bug#38180.

  • Partitioning: When a partitioned table had a TIMESTAMP column defined with CURRENT_TIMESTAMP as the default but with no ON UPDATE clause, the column's value was incorrectly set to CURRENT_TIMESTAMP when updating across partitions. (Bug#38272)

  • Partitioning: myisamchk failed with an assertion error when analyzing a partitioned MyISAM table. (Bug#37537)

  • Partitioning: A LIST partitioned MyISAM table returned erroneous results when an index was present on a column in the WHERE clause and NOT IN was used on that column.

    Searches using the index were also much slower then if the index were not present. (Bug#35931)

  • Partitioning: SELECT COUNT(*) was not correct for some partitioned tables using a storage engine that did not support HA_STATS_RECORDS_IS_EXACT. Tables using the ARCHIVE storage engine were known to be affected.

    This was because ha_partition::records() was not implemented, and so the default handler::records() was used in its place. However, this is not correct behavior if the storage engine does not support HA_STATS_RECORDS_IS_EXACT.

    The solution was to implement ha_partition::records() as a wrapper around the underlying partition records.

    As a result of this fix, the rows column in the output of EXPLAIN PARTITIONS now includes the total number of records in the partitioned table. (Bug#35745)

  • Partitioning: MyISAM recovery enabled with the --myisam-recover option did not work for partitioned MyISAM tables. (Bug#35161)

  • Partitioning: When one user was in the midst of a transaction on a partitioned table, a second user performing an ALTER TABLE on this table caused the server to hang. (Bug#34604)

  • Partitioning: Attempting to execute an INSERT DELAYED statement on a partitioned table produced the error Table storage engine for 'table' doesn't have this option, which did not reflect the source of the error accurately. The error message returned in such cases has been changed to DELAYED option not supported for table 'table'. (Bug#31210)

  • Replication: Some kinds of internal errors, such as Out of memory errors, could cause the server to crash when replicating statements with user variables.

    certain internal errors. (Bug#37150)

  • Replication: Row-based replication did not correctly copy TIMESTAMP values from a big-endian storage engine to a little-endian storage engine. (Bug#37076)

  • Replication: INSTALL PLUGIN and UNINSTALL PLUGIN caused row-based replication to fail.

    Note

    These statements are not replicated; however, when using row-based logging, the changes they introduce in the mysql system tables are written to the binary log.

    (Bug#35807)

  • Server-side cursors were not initialized properly, which could cause a server crash. (Bug#38486)

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

  • A failure to clean up binary log events was corrected (detected by Valgrind). (Bug#38290)

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

  • Queries containing a subquery with DISTINCT and ORDER BY could cause a server crash. (Bug#38191)

  • The fix for Bug#20748 caused a problem such that on Unix, MySQL programs looked for options in ~/my.cnf rather than the standard location of ~/.my.cnf. (Bug#38180)

  • If the table definition cache contained tables with many BLOB columns, much memory could be allocated to caching BLOB values. Now a size limit on the cached BLOB values is enforced. (Bug#38002)

  • For InnoDB tables, ORDER BY ... DESC sometimes returned results in ascending order. (Bug#37830)

  • 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 server returned unexpected results if a right side of the NOT IN clause consisted of the NULL value and some constants of the same type. For example, this query might return 3, 4, 5, and so forth if a table contained those values: 

    SELECT * FROM t WHERE NOT t.id IN (NULL, 1, 2);

    (Bug#37761)

  • Setting the session value of the innodb_table_locks system variable caused a server crash. (Bug#37669)

  • Nesting of IF() inside of SUM() could cause an extreme server slowdown. (Bug#37662)

  • Killing a query that used an EXISTS subquery as the argument to SUM() or AVG() caused a server crash. (Bug#37627)

  • When using indexed ORDER BY sorting, incorrect query results could be produced if the optimizer switched from a covering index to a noncovering index. (Bug#37548)

  • After TRUNCATE TABLE for an InnoDB table, inserting explicit values into an AUTO_INCREMENT column could fail to increment the counter and result in a duplicate-key error for subsequent insertion of NULL. (Bug#37531)

  • Within stored programs or prepared statements, REGEXP could return incorrect results due to improper initialization. (Bug#37337)

  • 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)

  • If the length of a field was 3, internal InnoDB to integer type conversion didn't work on big-endian machines in the row_search_autoinc_column() function. (Bug#36793)

  • 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)

  • The CSV storage engine returned success even when it failed to open a table's data file. (Bug#36638)

  • SELECT DISTINCT from a simple view on an InnoDB table, where all selected columns belong to the same unique index key, returned incorrect results. (Bug#36632)

  • 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)

  • If initialization of an INFORMATION_SCHEMA plugin failed, INSTALL PLUGIN freed some internal plugin data twice. (Bug#36399)

  • For InnoDB tables, the DATA_FREE column of the INFORMATION_SCHEMA.TABLES displayed free space in kilobytes rather than bytes. Now it displays bytes. (Bug#36278)

  • 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)

  • The mysql client failed to recognize comment lines consisting of -- followed by a newline. (Bug#36244)

  • The server could crash with an assertion failure (or cause the client to get a “Packets out of order” error) when the expected query result was that it should terminate with a “Subquery returns more than 1 row” error. (Bug#36135)

  • The UUID() function returned UUIDs with the wrong time; this was because the offset for the time part in UUIDs was miscalculated. (Bug#35848)

  • The configure script did not allow utf8_hungarian_ci to be specified as the default collation. (Bug#35808)

  • On 64-bit systems, assigning values of 2 63 – 1 or larger to key_buffer_size caused memory overruns. (Bug#35616)

  • For InnoDB tables, REPLACE statements used “traditional” style locking, regardless of the setting of innodb_autoinc_lock_mode. Now REPLACE works the same way as “simple inserts” instead of using the old locking algorithm. (REPLACE statements are treated in the same way as INSERT statements.) (Bug#35602)

  • Freeing of an internal parser stack during parsing of complex stored programs caused a server crash. (Bug#35577, Bug#37269, Bug#37228)

  • mysqlbinlog left temporary files on the disk after shutdown, leading to the pollution of the temporary directory, which eventually caused mysqlbinlog to fail. This caused problems in testing and other situations where mysqlbinlog might be invoked many times in a relatively short period of time. (Bug#35543)

  • Index scans performed with the sort_union() access method returned wrong results, caused memory to be leaked, and caused temporary files to be deleted when the limit set by sort_buffer_size was reached. (Bug#35477, Bug#35478)

  • Table checksum calculation could cause a server crash for FEDERATED tables with BLOB columns containing NULL values. (Bug#34779)

  • A significant slowdown occurred when many SELECT statements that return many rows from InnoDB tables were running concurrently. (Bug#34409)

  • mysql_install_db failed if the server was running with an SQL mode of TRADITIONAL. This program now resets the SQL mode internally to avoid this problem. (Bug#34159)

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

  • Fast ALTER TABLE operations were not fast for columns that used multibyte character sets. (Bug#33873)

  • The internal functions my_getsystime(), my_micro_time(), and my_micro_time_and_time() did not work correctly on Windows. One symptom was that uniqueness of UUID() values could be compromised. (Bug#33748)

  • Cached queries that used 256 or more tables were not properly cached, so that later query invalidation due to a TRUNCATE TABLE for one of the tables caused the server to hang. (Bug#33362)

  • mysql_upgrade attempted to use the /proc file system even on systems that do not have it. (Bug#31605)

  • mysql_install_db failed if the default storage engine was NDB. Now it explicitly uses MyISAM as the storage engine when running mysqld --bootstrap. (Bug#31315)

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

  • On NetWare, mysql_install_db could appear to execute normally even if it failed to create the initial databases. (Bug#30129)

  • The Serbian translation for the ER_INCORRECT_GLOBAL_LOCAL_VAR error was corrected. (Bug#29738)

  • TRUNCATE TABLE for InnoDB tables returned a count showing too many rows affected. Now the statement returns 0 for InnoDB tables. (Bug#29507)

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

  • In some cases, the parser interpreted the ; character as the end of input and misinterpreted stored program definitions. (Bug#26030)

  • The FLUSH PRIVILEGES statement did not produce an error when it failed. (Bug#21226)

  • After executing a prepared statement that accesses a stored function, the next execution would fail to find the function if the stored function cache was flushed in the meantime. (Bug#12093, Bug#21294)