Renamed the innodb.status.<pid> files (created in the data directory) to innodb_status.<pid>. This avoids problems on file systems that do not allow multiple periods in file names.

Added innodb_status_file system variable to mysqld to control whether output from SHOW INNODB STATUS is written to a innodb_status.<pid> file in the data directory. By default, the file is not created. To create it, start mysqld with the --innodb_status_file=1 option.

Changes for NetWare to exit InnoDB gracefully on NetWare even in a case of an assertion failure, instead of intentionally crashing the `mysqld' server process.

Fixed a bug in ON DELETE CASCADE and ON UPDATE CASCADE foreign key constraints: long chains of cascaded operations would cause a stack overflow and crash the server. Cascaded operations are now limited to 15 levels. (Bug#4446)

Fixed a possible bug in LOCK TABLES introduced in MySQL/InnoDB-4.0.19: The count of tables explicitly locked by a transaction was incremented only after the locks were granted, but decremented when the lock structures were destroyed.

Fixed a bug in UNLOCK TABLES in autocommit = 0 mode, introduced in MySQL/InnoDB-4.0.19: The memory allocated for some locks acquired by the transaction could be deallocated before those locks were released. The bug can lead to crashes and memory corruption of the buffer pool when the transaction acquires a large number of locks (table locks or row-level locks).

Increment the InnoDB watchdog timeout during CHECK TABLE. A long-running CHECK TABLE would cause InnoDB to complain about a 'long semaphore wait', and crash the server, if a query had to wait more than 600 seconds behind that CHECK TABLE operation. (Bug#2694)

If you configure innodb_additional_mem_pool_size so small that InnoDB memory allocation spills over from it, then every 4 billionth spill may cause memory corruption. A symptom is a printout like the one following in the .err log. The workaround is to make innodb_additional_mem_pool_size big enough to hold all memory allocation. Use SHOW INNODB STATUS to determine that there is plenty of free space available in the additional mem pool, and the total allocated memory stays rather constant.

InnoDB: Error: Mem area size is 0. Possibly a memory overrun of the
InnoDB: previous allocated area!
InnoDB: Apparent memory corruption: mem dump  len 500; hex

The special meaning of the table names innodb_monitor, innodb_lock_monitor, innodb_tablespace_monitor, innodb_table_monitor, and innodb_validate in CREATE TABLE and DROP TABLE statements was accidentally removed in MySQL/InnoDB-4.0.19. The diagnostic functions attached to these special table names (see Section 13.2.14.2, “SHOW ENGINE INNODB STATUS and the InnoDB Monitors”) are accessible again in MySQL/InnoDB-4.0.21.

When the private SQL parser of InnoDB was modified in MySQL/InnoDB-4.0.19 in order to allow the use of the apostrophe (“'”) in table and column names, the fix relied on a previously unused function mem_realloc(), whose implementation was incorrect. As a result, InnoDB can incorrectly parse column and table names as the empty string. The InnoDB realloc() implementation has been corrected in MySQL/InnoDB-4.0.21.

Fixed a glitch introduced in 4.0.18 and 4.1.2: in SHOW TABLE STATUS InnoDB systematically overestimated the row count by 1 if the table fit on a single 16 kB data page.

InnoDB created temporary files with the C library function tmpfile(). On Windows, the files would be created in the root directory of the current file system. To correct this behavior, the invocations of tmpfile() were replaced with code that uses the function create_temp_file() in the MySQL portability layer. (Bug#3998)

If ALTER TABLE ... DROP FOREIGN KEY ... fails because of a wrong constraint name, return a table handler error number 150 instead of 152.

If there was little file I/O in InnoDB, but the insert buffer was used, it could happen that 'Pending normal aio reads' was bigger than 0, but the I/O handler thread did not get waken up in 600 seconds. This resulted in a hang, and crashing of InnoDB.

If we RENAMEd a table, InnoDB forgot to load the FOREIGN KEY constraints that reference the new table name, and forgot to check that they are compatible with the table.