This release includes InnoDB Plugin 1.0.6. This version is considered of Release Candidate (RC) quality.

In this release, the InnoDB Plugin is included in source and binary distributions, except RHEL3, RHEL4, SuSE 9 (x86, x86_64, ia64), and generic Linux RPM packages. It also does not work for FreeBSD 6 and HP-UX or for Linux on S/390, PowerPC, and generic ia64.

Partitioning: The UNIX_TIMESTAMP() function is now supported in partitioning expressions using TIMESTAMP columns. For example, it now possible to create a partitioned table such as this one:

CREATE TABLE t (c TIMESTAMP) 
PARTITION BY RANGE ( UNIX_TIMESTAMP(c) ) (
    PARTITION p0 VALUES LESS THAN (631148400),
    PARTITION p1 VALUES LESS THAN (946681200),
    PARTITION p2 VALUES LESS THAN (MAXVALUE)
);

All other expressions involving TIMESTAMP values are now rejected with an error when attempting to create a new partitioned table or to alter an existing partitioned table.

When accessing an existing partitioned table having a timezone-dependent partitioning function (where the table was using a previous version of MySQL), a warning rather than an error is issued. In such cases, you should fix the table. One way of doing this is to alter the table's partitioning expression so that it uses UNIX_TIMESTAMP(). (Bug#42849)

Performance: Partitioning: When used on partitioned tables, the records_in_range handler call checked more partitions than necessary. The fix for this issue reduces the number of unpruned partitions checked for statistics in partition range checking, which has resulted in some partition operations being performed up to 2-10 times faster than before this change was made, when testing with tables having 1024 partitions. (Bug#48846)

See also Bug#37252, Bug#47261.

Security Fix: For servers built with yaSSL, a preauthorization buffer overflow could cause memory corruption or a server crash. We thank Evgeny Legerov from Intevydis for providing us with a proof-of-concept script that allowed us to reproduce this bug. (Bug#50227, CVE-2009-4484)

Important Change: Replication: The RAND() function is now marked as unsafe for statement-based replication. Using this function now generates a warning when binlog_format=STATEMENT and causes the the format to switch to row-based logging when binlog_format=MIXED.

This change is being introduced because, when RAND() was logged in statement mode, the seed was also written to the binary log, so the replication slave generated the same sequence of random numbers as was generated on the master. While this could make replication work in some cases, the order of affected rows was still not guaranteed when this function was used in statements that could update multiple rows, such as UPDATE or INSERT ... SELECT; if the master and the slave retrieved rows in different order, they began to diverge. (Bug#49222)

Partitioning: A query that searched on a ucs2 column failed if the table was partitioned. (Bug#48737)

Replication: A LOAD DATA INFILE statement that loaded data into a table having a column name that had to be escaped (such as `key` INT) caused replication to fail when logging in mixed or statement mode. In such cases, the master wrote the LOAD DATA event into the binary log without escaping the column names. (Bug#49479)

See also Bug#47927.

Replication: Spatial data types caused row-based replication to crash. (Bug#48776)

Replication: A flaw in the implementation of the purging of binary logs could result in orphaned files being left behind in the following circumstances:

In addition, if the slave was not connected during the purge operation, it was possible for a log file that was in use to be removed; this could lead data loss and possible inconsistencies between the master and slave. (Bug#45292)

Replication: When using the STATEMENT or MIXED logging format, the statements LOAD DATA CONCURRENT LOCAL INFILE and LOAD DATA CONCURRENT INFILE were logged as LOAD DATA LOCAL INFILE and LOAD DATA LOCAL INFILE, respectively (in other words, the CONCURRENT keyword was omitted). As a result, when using replication with either of these logging modes, queries on the slaves were blocked by the replication SQL thread while trying to execute the affected statements. (Bug#34628)

Replication: Manually removing entries from the binary log index file on a replication master could cause the server to repeatedly send the same binary log file to slaves. (Bug#28421)

Cluster Replication: When expire_logs_days was set, the thread performing the purge of the log files could deadlock, causing all binary log operations to stop. (Bug#49536)

Within a stored routine, selecting the result of CONCAT_WS() with a routine parameter argument into a user variable could return incorrect results. (Bug#50096)

The IBMDB2I storage engine was missing from the i5os 64-bit distribution of MySQL 5.1.42. It is now included again. (Bug#50059)

EXPLAIN EXTENDED UNION ... ORDER BY caused a crash when the ORDER BY referred to a nonconstant or full-text function or a subquery. (Bug#49734)

The push_warning_printf() function was being called with an invalid error level MYSQL_ERROR::WARN_LEVEL_ERROR, causing an assertion failure. To fix the problem, MYSQL_ERROR::WARN_LEVEL_ERROR has been replaced by MYSQL_ERROR::WARN_LEVEL_WARN. (Bug#49638)

Some prepared statements could raise an assertion when re-executed. (Bug#49570)

A Valgrind error in make_cond_for_table_from_pred() was corrected. Thanks to Sergey Petrunya for the patch to fix this bug. (Bug#49506)

When compiling on Windows, an error in the CMake definitions for InnoDB would cause the engine to be built incorrectly. (Bug#49502)

Valgrind warnings for CHECKSUM TABLE were corrected. (Bug#49465)

Specifying an index algorithm (such as BTREE) for SPATIAL or FULLTEXT indexes caused a server crash. These index types do not support algorithm specification, and it is now disallowed to do so. (Bug#49250)

The optimizer sometimes incorrectly handled conditions of the form WHERE col_name='const1' AND col_name='const2'. (Bug#49199)

Execution of DECODE() and ENCODE() could be inefficient because multiple executions within a single statement reinitialized the random generator multiple times even with constant parameters. (Bug#49141)

MySQL 5.1 does not support 2-byte collation numbers, but did not check the number and crashed for out-of-range values. (Bug#49134)

With binary logging enabled, REVOKE ... ON {PROCEDURE|FUNCTION} FROM ... could cause a crash. (Bug#49119)

The LIKE operator did not work correctly when using an index for a ucs2 column. (Bug#49028)

check_key_in_view() was missing a DBUG_RETURN in one code branch, causing a crash in debug builds. (Bug#48995)

Several strmake() calls had an incorrect length argument (too large by one). (Bug#48983)

On Fedora 12, strmov() did not guarantee correct operation for overlapping source and destination buffer. Calls were fixed to use an overlap-safe version instead. (Bug#48866)

Incomplete reset of internal TABLE structures could cause a crash with eq_ref table access in subqueries. (Bug#48709)

Re-execution of a prepared statement could cause a server crash. (Bug#48508)

The error message for ER_UPDATE_INFO was subject to buffer overflow or truncation. (Bug#48500)

SHOW BINLOG EVENTS could fail with a error: Wrong offset or I/O error. (Bug#48357)

Valgrind warnings related to binary logging of LOAD DATA INFILE statements were corrected. (Bug#48340)

An aliasing violation in the C API could lead to a crash. (Bug#48284)

With one thread waiting for a lock on a table, if another thread dropped the table and created a new table with the same name and structure, the first thread would not notice that the table had been re-created and would try to used cached metadata that belonged to the old table but had been freed. (Bug#48157)

The InnoDB Monitor could fail to print diagnostic information after a long lock wait. (Bug#47814)

Queries containing GROUP BY ... WITH ROLLUP that did not use indexes could return incorrect results. (Bug#47650)

If an invocation of a stored procedure failed in the table-open stage, subsequent invocations that did not fail in that stage could cause a crash. (Bug#47649)

On Solaris, no stack trace was printed to the error log after a crash. (Bug#47391)

A crash occurred when a user variable that was assigned to a subquery result was used as a result field in a SELECT statement with aggregate functions. (Bug#47371)

The first execution of STOP SLAVE UNTIL stopped too early. (Bug#47210)

When the mysql client was invoked with the --vertical option, it ignored the --skip-column-names option. (Bug#47147)

It was possible for init_available_charsets() not to initialize correctly. (Bug#45058)

For a VARCHAR(N) column, ORDER BY BINARY(col_name) sorted using only the first N bytes of the column, even though column values could be longer than N bytes if they contained multibyte characters. (Bug#44131)

Comparison with NULL values sometimes did not produce a correct result. (Bug#42760)

Crash recovery did not work for InnoDB temporary tables. (Bug#41609)

The mysql_upgrade command would create three additional fields to the mysql.proc table (character_set_client, collation_connection, and db_collation), but did not populate the fields with correct values. This would lead to error messages reported during stored procedure execution. (Bug#41569)

When compressed MyISAM files were opened, they were always memory mapped, sometimes causing memory-swapping problems. To deal with this, a new system variable, myisam_mmap_size, was added to limit the amount of memory used for memory mapping of MyISAM files. (Bug#37408)

A race condition on the privilege hash tables allowed one thread to try to delete elements that had already been deleted by another thread. A consequence was that SET PASSWORD or FLUSH PRIVILEGES could cause a crash. (Bug#35589, Bug#35591)

ALTER TABLE with both DROP COLUMN and ADD COLUMN clauses could crash or lock up the server. (Bug#31145)