Hi!

InnoDB is the MySQL table type that supports FOREIGN KEY constraints, row-level locking, Oracle-style consistent, non-locking SELECTs, multiple tablespaces, and a non-free online hot backup tool.

Release 4.1.9 is mainly a bugfix release. This release fixes the CRITICAL BUG #7496 in the innodb_file_per_table option of my.cnf. Secondary indexes of a table could get corrupt at a mysqld shutdown. I recommend that all users of InnoDB with that my.cnf option immediately upgrade to MySQL-4.1.9!

OS X 10.3 users should also consider upgrading to 4.1.9. Apple disabled fsync() for internal disk drives, and replaced it with a special fcntl() file flush method. A power outage can easily lead to database corruption in OS X 10.3 with older MySQL versions.

Except of critical bug #7496, 4.1.8 has been a very good release, and if we do not discover any serious bugs in 4.1.9 in the next few weeks, I can recommend production use of 4.1.9.


Functionality added or changed:

* Do not acquire an internal InnoDB table lock in LOCK TABLES if AUTOCOMMIT=1. This helps in porting old MyISAM applications to InnoDB. InnoDB table locks in that case caused very easily deadlocks.

* Print a more descriptive error and refuse to start InnoDB if the size of ibdata files is smaller than what is stored in the tablespace header; innodb_force_recovery overrides this.


Bugs fixed:

* Fixed the critical bug if you enabled innodb_file_per_table in my.cnf. If you shut down mysqld, records could disappear from the secondary indexes of a table. (Bug #7496)

* Fixed a bug: 32-bit mysqld binaries built on HP-UX-11 did not work with InnoDB files greater than 2 GB in size. (Bug #6189)

* Return a sensible error code from DISCARD TABLESPACE if it fails because the table is referenced by a FOREIGN KEY.

* Fixed a bug: InnoDB failed to drop a table in the background drop queue if the table was referenced by a FOREIGN KEY constraint.

* Fixed a bug: if we dropped a table where an INSERT was waiting for a lock to check a FOREIGN KEY constraint, then an assertion would fail in lock_reset_all_on_table().

* Fix a little bug: we looked at the physical size of a stored SQL NULL value from a wrong field in the index; this has probably caused no bugs visible to the user, only caused some extra space usage in some rare cases.

* Use the fcntl() file flush method on OS X versions >= 10.3. Apple had disabled fsync() in OS X for internal disk drives, which caused corruption at power outages.


Upgrading to 4.1.9:

* If you have created or used InnoDB tables with TIMESTAMP columns in MySQL versions 4.1.0-4.1.3, you have to rebuild those tables when you upgrade to MySQL-4.1.4 or later. The storage format in those MySQL versions for a TIMESTAMP column was wrong. If you upgrade from 4.0 to 4.1.4 or later, then no rebuild of TIMESTAMP tables is needed.

* If you have stored characters < ASCII(32) to non-latin1 non-BINARY indexed columns in MySQL versions <= 4.1.2, then you have to rebuild those tables after you upgrade to >= 4.1.3. The reason is that the sorting order of those characters and the space character changes for some character sets in 4.1.3. See the MySQL/InnoDB-4.1.3 changelog for a precise description of the cases where you need to rebuild the table. Also MyISAM tables have to be rebuilt or repaired in these cases.

* If you have used column prefix indexes on UTF-8 columns or other multibyte character set columns in 4.1.0 - 4.1.5, you have to rebuild the tables when you upgrade to 4.1.6 or later.

* If you have used accent characters (ASCII codes >= 128) in database names, table names, constraint names, or column names in versions < 4.1, you cannot upgrade to 4.1 directly, because 4.1 uses UTF-8 to store metadata names. Use RENAME TABLE to overcome this if the accent character is in the table name or the database name, or rebuild the table.


Best regards,

Heikki Tuuri
Innobase Oy
http://www.innodb.com




-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]



Reply via email to