Skip navigation links
MySQL 3.23, 4.0, 4.1 Reference Manual :: B MySQL Change History :: B.4 Changes in InnoDB :: B.4.2 Changes in MySQL/InnoDB-4.1.4, August 31, 2004
B.4.3 Changes in MySQL/InnoDB-4.1.3, June 28, 2004 »
Section Navigation      [Toggle]

B.4.2. Changes in MySQL/InnoDB-4.1.4, August 31, 2004

Functionality added or changed:

  • Important

    Made internal representation of TIMESTAMP values in InnoDB in 4.1 to be the same as in 4.0. This difference resulted in incorrect datetime values in TIMESTAMP columns in InnoDB tables after an upgrade from 4.0 to 4.1. (Bug#4492) Warning: extra steps during upgrade required! This means that if you are upgrading from 4.1.x, where x <= 3, to 4.1.4 you should use mysqldump for saving and then restoring your InnoDB tables with TIMESTAMP columns. No conversion is needed if you upgrade from 3.23 or 4.0 to 4.1.4 or later.

  • Added a new startup option innodb_locks_unsafe_for_binlog. This option forces InnoDB not to use next-key locking in searches and index scans.

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

  • “Gap” type row locks without the LOCK_INSERT_INTENTION flag do not need to wait for anything. This is because different users can have conflicting lock types on gaps. This change reduces unnecessary deadlocks.

Bugs fixed:

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

  • Increment the InnoDB watchdog timeout during CHECK TABLE. (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. 

    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

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

  • 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 an intentional crashing of mysqld.