MySQL/InnoDB-4.1.8 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.8 is mainly a bugfix release. There was a critical bug
associated with the innobackup Perl script in 4.1.7: the second run of
innobackup would make the mysqld server to hang. Otherwise, 4.1.7 has been a
very good release, and if we do not discover any serious bugs in 4.1.8 in
the next few weeks, I can recommend production use of 4.1.8.


Functionality added or changed:

* Do not periodically write SHOW INNODB STATUS information to a temporary
file unless the configuration option innodb_status_file=1 is set.

* Commit after every 10,000 copied rows when executing ALTER TABLE. This
makes it much faster to recover from an aborted ALTER TABLE or OPTIMIZE
TABLE.

* mysqldump --single-transaction --master-data now is able to take an online
(non-blocking) dump of InnoDB and report the corresponding binary log
coordinates. This makes a backup suitable for point-in-time recovery,
roll-forward or replication slave creation.


Bugs fixed:

* A sequence of BEGIN (or SET AUTOCOMMIT=0), FLUSH TABLES WITH READ LOCK,
transactional update, COMMIT, FLUSH TABLES WITH READ LOCK could hang the
connection forever and possibly the MySQL server itself. This happened for
example when running the innobackup script several times. (Bug #6732)

* Do not intentionally crash mysqld if the buffer pool is exhausted by the
lock table; return error 1206 instead. Do not intentionally crash mysqld if
we cannot allocate the memory for the InnoDB buffer pool. (Bug #6817) (Bug
#6827)

* Let InnoDB's FOREIGN KEY parser to remove the latin1 character @code{0xA0}
from the end of an unquoted identifier. The EMS MySQL Manager in ALTER TABLE
adds that character after a table name, which caused error 121 when we tried
to add a new constraint.

* Refuse to open new-style tables created with MySQL 5.0.3 or later. (Bug
#7089)

* Do not call rewind() when displaying SHOW INNODB STATUS information on
stderr.

* Made the foreign key parser better aware of quotes. (Bug #6340)

* If one used INSERT IGNORE to insert several rows at a time, and the first
inserts were ignored because of a duplicate key collision, then InnoDB in a
replication slave assigned AUTO_INCREMENT values 1 bigger than in the
master. This broke the MySQL replication. (Bug #6287)

* Fixed a bug: InnoDB ignored in innodb_data_file_path the max specification
in :autoextend:max:2000M. This bug was introduced in 4.1.1.

* Fixed a bug: innodb_locks_unsafe_for_binlog still uses next-key locking
(Bug #6747). InnoDB used next-key locking when record matched completely to
search tuple. This unnecessary next-key locking is now removed when
innodb_locks_unsafe_for_binlog option is used.

* Fix two hangs: FOREIGN KEY constraints treated table and database names as
case-insensitive. RENAME TABLE t TO T would hang in an endless loop if t had
a foreign key constraint defined on it. Fix also a hang over the dictionary
mutex that would occur if one tried in ALTER TABLE or RENAME TABLE to create
a foreign key constraint name that collided with another existing name. (Bug
#3478)


Upgrading to 4.1.8:

* 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