7.5.15.1 MySQL/InnoDB-4.0.14, July 22, 2003

• InnoDB now supports the SAVEPOINT and ROLLBACK TO SAVEPOINT SQL statements. See http://www.innodb.com/ibman.html#Savepoints for the syntax.
• You can now create column prefix keys like in CREATE TABLE t (a BLOB, INDEX (a(10))).
• You can also use O_DIRECT as the innodb_flush_method on the latest versions of Linux and FreeBSD. Beware of possible bugs in those operating systems, though.
• Fixed the checksum calculation of data pages. Previously most OS file system corruption went unnoticed. Note that if you downgrade from version >= 4.0.14 to an earlier version < 4.0.14 then in the first startup(s) InnoDB will print warnings:

  InnoDB: Warning: an inconsistent page in the doublewrite buffer
  InnoDB: space id 2552202359 page number 8245, 127'th page in dblwr buf.
  

  but that is not dangerous and can be ignored.
• Modified the buffer pool replacement algorithm so that it tries to flush modified pages if there are no replaceable pages in the last 10 % of the LRU list. This can reduce disk i/o if the workload is a mixture of reads and writes.
• The buffer pool checkpoint flush algorithm now tries to flush also close neighbors of the page at the end of the flush list. This can speed up database shutdown, and can also speed up disk writes if InnoDB log files are very small compared to the buffer pool size.
• In 4.0.13 we made SHOW INNODB STATUS to print detailed info on the latest UNIQUE KEY error, but storing that info could slow down REPLACE significantly. We no longer store or print the info.
• Fixed a bug: SET FOREIGN_KEY_CHECKS=0 was not replicated properly in the MySQL replication. The fix will not be backported to 3.23.
• Fixed a bug: the parameter innodb_max_dirty_pages_pct forgot to take into account the free pages in the buffer pool. This could lead to excessive flushing even though there were lots of free pages in the buffer pool. Workaround: SET GLOBAL innodb_max_dirty_pages_pct = 100.
• Fixed a bug: if there were big index scans then a file read request could starve and InnoDB could assert because of a very long semaphore wait.
• Fixed a bug: if AUTOCOMMIT=1 then inside LOCK TABLES MySQL failed to do the commit after an updating SQL statement if binlogging was not on, and for SELECTs did not commit regardless of binlogging state.
• Fixed a bug: InnoDB could make the index page directory corrupt in the first B-tree page splits after a mysqld startup. A symptom would be an assertion in page0page.c, in function page_dir_find_slot().
• Fixed a bug: if in a FOREIGN KEY with an UPDATE CASCADE clause the parent column was of a different internal storage length than the child column, then a cascaded update would make the column length wrong in the child table and corrupt the child table. Because of MySQL's 'silent column specification changes' a fixed-length CHAR column can change internally to a VARCHAR and cause this error.
• Fixed a bug: if a non-latin1 character set was used and if in a FOREIGN KEY the parent column was of a different internal storage length than the child column, then all inserts to the child table would fail in a foreign key error.
• Fixed a bug: InnoDB could complain that it cannot find the clustered index record, or in rare cases return an extraneous row if a rollback, purge, and a SELECT coincided.
• Fixed a possible hang over the btr0sea.c latch if SELECT was used inside LOCK TABLES.
• Fixed a bug: contrary to what the release note of 4.0.13 said, the group commit still did not work if the MySQL binlogging was on.
• Fixed a bug: os_event_wait() did not work properly in Unix, which might have caused starvation in various log operations.
• Fixed a bug: if a single DELETE statement first managed to delete some rows and then failed in a FOREIGN KEY error or a 'Table is full error', MySQL did not roll back the whole SQL statement as it should, and also wrote the failed statement to the binlog, reporting there a non-zero error_code.
• Fixed a bug: the maximum allowed number of columns in a table is 1000, but InnoDB did not check that limit in CREATE TABLE, and a subsequent INSERT or SELECT from that table could cause an assertion.

User Comments

Add your own comment.