MySQL/InnoDB-4.1.9 is released

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/mysql?unsub=gcdmg-mysql@m.gmane.org