InnoDB Plugin has been upgraded to version 1.0.5. This version is considered of Release Candidate (RC) quality. The InnoDB Plugin Change History may contain information in addition to those changes reported here.

The InnoDB buffer pool is divided into two sublists: A new sublist containing blocks that are heavily used by queries, and an old sublist containing less-used blocks and from which candidates for eviction are taken. In the default operation of the buffer pool, a block when read in is loaded at the midpoint and then moved immediately to the head of the new sublist as soon as an access occurs. In the case of a table scan (such as performed for a mysqldump operation), each block read by the scan ends up moving to the head of the new sublist because multiple rows are accessed from each block. This occurs even for a one-time scan, where the blocks are not otherwise used by other queries. Blocks may also be loaded by the read-ahead background thread and then moved to the head of the new sublist by a single access. These effects can be disadvantageous because they push blocks that are in heavy use by other queries out of the new sublist to the old sublist where they become subject to eviction.

InnoDB Plugin now provides two system variables that enable LRU algorithm tuning:

For additional information, see Section 7.4.6, “The InnoDB Buffer Pool”. (Bug#45015)

For InnoDB Plugin, two status variables have been added to SHOW STATUS output. Innodb_buffer_pool_read_ahead and Innodb_buffer_pool_read_ahead_evicted indicate the number of pages read in by the InnoDB read-ahead background thread, and the number of such pages evicted without ever being accessed, respectively. Also, the status variables Innodb_buffer_pool_read_ahead_rnd and Innodb_buffer_pool_read_ahead_seq status variables have been removed.

The built-in version of InnoDB is not affected by these changes. (Bug#42885)

The server now supports a Debug Sync facility for thread synchronization during testing and debugging. To compile in this facility, configure MySQL with the --enable-debug-sync option. The debug_sync system variable provides the user interface Debug Sync. mysqld and mysql-test-run.pl support a --debug-sync-timeout option to enable the facility and set the default synchronization point timeout.

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. (Bug#32167, CVE-2008-2079)

See also Bug#39277.

Security Fix: MySQL clients linked against OpenSSL can be tricked not to check server certificates. (Bug#47320, CVE-2009-4028)

Partitioning: An ALTER TABLE ... ADD PARTITION statement that caused open_files_limit to be exceeded led to a crash of the MySQL server. (Bug#46922)

See also Bug#47343.

Partitioning: The cardinality of indexes on partitioned tables was calculated using the first partition in the table, which could result in suboptimal query execution plans being chosen. Now the partition having the most records is used instead, which should result in better use of indexes and thus improved performance of queries against partitioned tables in many if not most cases. (Bug#44059)

Replication: This issue occurred in MySQL 5.1.40 only. (Bug#48297)

Replication: When a session was closed on the master, temporary tables belonging to that session were logged with the wrong database names when either of the following conditions was true:

(Bug#48216)

See also Bug#46861, Bug#48297.

Replication: When using row-based replication, changes to nontransactional tables that occurred early in a transaction were not immediately flushed upon committing a statement. This behavior could break consistency since changes made to nontransactional tables become immediately visible to other connections. (Bug#47678)

See also Bug#47287, Bug#46864, Bug#43929, Bug#46129.

Replication: When mysqlbinlog --verbose was used to read a binary log that had been recorded using the row-based format, the output for events that updated some but not all columns of tables was not correct. (Bug#47323)

Replication: When using the row-based format to replicate a transaction involving both transactional and nontransactional engines, which contained a DML statement affecting multiple rows, the statement failed; if this transaction was followed by a COMMIT, the master and the slave could diverge, because the statement was correctly rolled back on the master, but was applied on the slave. (Bug#47287)

See also Bug#46864.

Replication: A problem with the BINLOG statement in the output of mysqlbinlog could break replication; statements could be logged with the server ID stored within events by the BINLOG statement rather than the ID of the running server. With this fix, the server ID of the server executing the statements can no longer be overridden by the server ID stored in the binary log's format description statement. (Bug#46640)

This regression was introduced by Bug#32407.

Replication: When using statement-based replication and the transaction isolation level was set to READ COMMITTED or a less strict level, InnoDB returned an error even if the statement in question was filtered out according to the --binlog-do-db or --binlog-ignore-db rules in effect at the time. (Bug#42829)

Replication: FLUSH LOGS did not actually close and reopen the binary log index file. (Bug#34582)

See also Bug#5.0.90.

SUM() artificially increased the precision of a DECIMAL argument, which was truncated when a temporary table was created to hold the results. (Bug#48370)

See also Bug#45261.

If an outer query was invalid, a subquery might not even be set up. EXPLAIN EXTENDED did not expect this and caused a crash by trying to dereference improperly set up information. (Bug#48295)

A query containing a view using temporary tables and multiple tables in the FROM clause and PROCEDURE ANALYSE() caused a server crash.

As a result of this bug fix, PROCEDURE ANALYSE() is legal only in a top-level SELECT. (Bug#48293)

See also Bug#46184.

Error handling was missing for SELECT statements containing subqueries in the WHERE clause and that assigned a SELECT result to a user variable. The server could crash as a result. (Bug#48291)

An assertion could fail if the optimizer used a SPATIAL index. (Bug#48258, Bug#47019)

Memory-allocation failures were handled incorrectly in the InnoDB os_mem_alloc_large() function. (Bug#48237)

WHERE clauses with outer_value_list NOT IN subquery were handled incorrectly if the outer value list contained multiple items at least one of which could be NULL. (Bug#48177)

A combination of GROUP BY WITH ROLLUP, DISTINCT and the const join type in a query caused a server crash when the optimizer chose to employ a temporary table to resolve DISTINCT. (Bug#48131)

In some cases, using a null microsecond part in a WHERE condition (for example, WHERE date_time_field <= 'YYYY-MM-DD HH:MM:SS.0000') could lead to incorrect results due to improper DATETIME comparison. (Bug#47963)

A build configured using the --without-server option did not compile the yaSSL code, so if --with-ssl was also used, the build failed. (Bug#47957)

When a query used a DATE or DATETIME value formatted using any separator characters other than hyphen ('-') and a >= condition matching only the greatest value in an indexed column, the result was empty if an index range scan was employed. (Bug#47925)

mysys/mf_keycache.c requires threading, but no test was made for thread support. (Bug#47923)

For debug builds, an assertion could fail during the next statement executed for a temporary table after a multiple-table UPDATE involving that table and modified an AUTO_INCREMENT column with a user-supplied value. (Bug#47919)

The mysys/mf_strip.c file, which defines the strip_sp() function, has been removed from the MySQL source. The function was no longer used within the main build, and the supplied function was causing symbol errors on Windows builds. (Bug#47857)

The Windows build for MySQL would compile the split.c and debug.c files unnecessarily, causing additional symbols to be included in mysqld. (Bug#47850)

When building storage engines on Windows it was not possible to specify additional libraries within the CMake file required for the build. An ${engine}_LIBS macro has been added to the files to support these additional storage-engine specific libraries. (Bug#47797)

When building a pluggable storage engine on Windows, the engine name could be based on the directory name where the engine was located, rather than the configured storage engine name. (Bug#47795)

During cleanup of a stored procedure's internal structures, the flag to ignore the errors for INSERT IGNORE or UPDATE IGNORE was not cleaned up, which could result in a server crash. (Bug#47788)

If the first argument to GeomFromWKB() function was a geometry value, the function just returned its value. However, it failed to preserve the argument's null_value flag, which caused an unexpected NULL value to be returned to the caller, resulting in a server crash. (Bug#47780)

InnoDB could crash when updating spatial values. (Bug#47777)

On WIndows, when an idle named pipe connection was forcibly closed with a KILL statement or because the server was being shut down, the thread that was closing the connection would hang infinitely. (Bug#47571, Bug#31621)

A function call could end without throwing an error or setting the return value. For example, this could happen when an error occurred while calculating the return value. This is fixed by setting the value to NULL when an error occurs during evaluation of an expression. (Bug#47412)

A simple SELECT with implicit grouping could return many rows rather than a single row if the query was ordered by the aggregated column in the select list. (Bug#47280)

An assertion could be raised for CREATE TABLE if there was a pending INSERT DELAYED or REPLACE DELAYED for the same table. (Bug#47274)

InnoDB raised errors in some cases in a manner not compatible with SIGNAL and RESIGNAL. (Bug#47233)

If an InnoDB table was created with the AUTO_INCREMENT table option to specify an initial auto-increment value, and an index was added in a separate operation later, the auto-increment value was lost (subsequent inserts began at 1 rather than the specified value). (Bug#47125)

Incorrect handling of predicates involving NULL by the range optimizer could lead to an infinite loop during query execution. (Bug#47123)

Repair by sort or parallel repair of MyISAM tables could fail to fail over to repair with key cache. (Bug#47073)

InnoDB Plugin did not compile on some Solaris systems. (Bug#47058)

On WIndows, when a failed I/O operation occurred with return code of ERROR_WORKING_SET_QUOTA, InnoDB intentionally crashed the server. Now InnoDB sleeps for 100ms and retries the failed operation. (Bug#47055)

InnoDB now ignores negative values supplied by a user for an AUTO_INCREMENT column when calculating the next value to store in the data dictionary. Setting AUTO_INCREMENT columns to negative values is undefined behavior and this change should bring the behavior of InnoDB closer to what users expect. (Bug#46965)

When MySQL crashed (or a snapshot was taken that simulates a crash), it was possible that internal XA transactions (used to synchronize the binary log and InnoDB) could be left in a PREPARED state, whereas they should be rolled back. This occurred when the server_id value changed before the restart, because that value was used to construct XID values.

Now the restriction is relaxed that the server_id value be consistent for XID values to be considered valid. The rollback phase should then be able to clean up all pending XA transactions. (Bug#46944)

InnoDB Plugin did not compile using gcc 4.1 on PPC systems. (Bug#46718)

If InnoDB Plugin reached its limit on the number of concurrent transactions (1023), it wrote a descriptive message to the error log but returned a misleading error message to the client, or an assertion failure occurred. (Bug#46672)

See also Bug#18828.

A Valgrind error during index creation by InnoDB Plugin was corrected. (Bug#46657)

Concurrent INSERT INTO ... SELECT statements for an InnoDB table could cause an AUTO_INCREMENT assertion failure. (Bug#46650)

If a transaction was rolled back inside InnoDB due to a deadlock or lock wait timeout, and a statement in the transaction had an IGNORE clause, the server could crash at the end of the statement or on shutdown. (Bug#46539)

Trailing spaces were not ignored for user-defined collations that mapped spaces to a character other than 0x20. (Bug#46448)

See also Bug#29468.

The GPL and commercial license headers had different sizes, so that error log, backtrace, core dump, and cluster trace file line numbers could be off by one if they were not checked against the version of the source used for the build. (For example, checking a GPL build backtrace against commercial sources.) (Bug#46216)

InnoDB did not disallow creation of an index with the name GEN_CLUST_INDEX, which is used internally. (Bug#46000)

During the build of the Red Hat IA64 MySQL server RPM, the system library link order was incorrect. This made the resulting Red Hat IA64 RPM depend on "libc.so.6.1(GLIBC_PRIVATE)(64bit)", thus preventing installation of the package. (Bug#45706)

The caseinfo member of the CHARSET_INFO structure was not initialized for user-defined Unicode collations, leading to a server crash. (Bug#45645)

With InnoDB Plugin, renaming a table column and then creating an index on the renamed column caused a server crash to the .frm file and the InnoDB data directory going out of sync. Now InnoDB Plugin 1.0.5 returns an error instead: ERROR 1034 (HY000): Incorrect key file for table 'tbl_name'; try to repair it. To work around the problem, create another table with the same structure and copy the original table to it. (Bug#44571)

An InnoDB error message incorrectly referred to the nonexistent innodb_max_files_open variable rather than to innodb_open_files. (Bug#44338)

For ALTER TABLE, renaming a DATETIME or TIMESTAMP column unnecessarily caused a table copy operation. (Bug#43508)

The weekday names for the Romanian lc_time_names locale 'ro_RO' were incorrect. Thanks to Andrei Boros for the patch to fix this bug. (Bug#43207)

XA START could cause an assertion failure or server crash when it is called after a unilateral rollback issued by the Resource Manager (both in a regular transaction and after an XA transaction). (Bug#43171)

The FORCE INDEX FOR ORDER BY index hint was ignored when join buffering was used. (Bug#43029)

Incorrect handling of range predicates combined with OR operators could yield incorrect results. (Bug#42846)

Failure to treat BIT values as unsigned could lead to unpredictable results. (Bug#42803)

For the embedded server on Windows, InnoDB crashed when innodb_file_per_table was enabled and a table name was in full path format. (Bug#42383)

Some queries with nested outer joins could lead to crashes or incorrect results because an internal data structure was handled improperly. (Bug#42116)

In a replication scenario with innodb_locks_unsafe_for_binlog enabled on the slave, where rows were changed only on the slave (not through replication), in some rare cases, many messages of the following form were written to the slave error log: InnoDB: Error: unlock row could not find a 4 mode lock on the record. (Bug#41756)

After renaming a user, granting that user privileges could result in the user having additional privileges other than those granted. (Bug#41597)

With a nonstandard InnoDB page size, some error messages became inaccurate.

(Bug#41490)

In some cases, the server did not recognize lettercase differences between GRANT attributes such as table name or user name. For example, a user was able to perform operations on a table with privileges of another user with the same user name but in a different lettercase.

In consequence of this bug fix, the collation for the Routine_name column of the mysql.proc table is changed from utf8_bin to utf8_general_ci. (Bug#41049)

See also Bug#48872.

Simultaneous ANALYZE TABLE operations for an InnoDB tables could be subject to a race condition. (Bug#38996)

Previously, InnoDB performed REPLACE INTO T SELECT ... FROM S WHERE ... by setting shared next-key locks on rows from S. Now InnoDB selects rows from S with shared locks or as a consistent read, as for INSERT ... SELECT. This reduces lock contention between sessions. (Bug#37232)

When an InnoDB tablespace filled up, an error was logged to the client, but not to the error log. Also, the error message was misleading and did not indicate the real source of the problem. (Bug#31183)

In mysql, using Control-C to kill the current query resulted in a ERROR 1053 (08S01): Server shutdown in progress" message if the query was waiting for a lock. (Bug#28141)