Dear MySQL users,
MySQL Server 5.5.5-m3, a new version of the popular Open Source Database Management System, has been released. The "-m3" suffix indicates that these releases belong to the third milestone. According to our "milestone" release model, also called "Celosia". You can read more about the release model and the planned milestones at http://forge.mysql.com/wiki/Development_Cycle The new features in these releases are of beta quality. As with any other pre-production release, caution should be taken when installing on production level systems or systems with critical data. Please note that *downgrading* from these releases to a previous release series, including MySQL Server 5.5 milestone 2 (Betony) releases, is not supported. For production level systems using 5.1, we would like to direct your attention to the product description of MySQL Enterprise at: http://mysql.com/products/enterprise/ MySQL 5.5 is based on MySQL 5.4, which won't get any further updates. MySQL 5.5 includes several high-impact changes to address scalability and performance issues in MySQL Server. These changes exploit advances in hardware and CPU design and enable better utilization of existing hardware. For an overview of what's new in MySQL 5.5, please see the section "What Is New in MySQL 5.5" online at http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html For information on installing MySQL 5.5.5-m3 on new servers, please see the MySQL installation documentation at http://dev.mysql.com/doc/refman/5.5/en/installing.html For upgrading from previous MySQL releases, please see the important upgrade considerations at http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html <http://dev.mysql.com/doc/refman/5.5/en/installing.html> MySQL Server 5.5 is available in source and binary form for a number of platforms from the "Development Releases" selection of our download pages at http://dev.mysql.com/downloads/mysql/ Not all mirror sites may be up to date at this point in time, so if you can't find this version on some mirror, please try again later or choose another download site. We welcome and appreciate your feedback, bug reports, bug fixes, patches, etc.: http://forge.mysql.com/wiki/Contributing The complete list of all "Bugs Fixed" may be viewed online at _http://dev.mysql.com/doc/refman/5.5/en/news-5-5-5.html_ Special note for those of you who build from source: In MySQL 5.5.5-m3, CMake joins GNU autotools as a build framework for all platforms. We've previously already used CMake on Windows. Our existing support for GNU autotools isn't going away just yet, but if you are so inclined, you can now alternatively use CMake as per the instructions on the web page linked below. The official packages for this release are the first to be produced using CMake. As always, we value your feedback! http://forge.mysql.com/wiki/CMake Changes in MySQL 5.5.5: |InnoDB is now the default storage engine, rather than MyISAM in||| the regular versions of MySQL. This change has the following consequences: * Existing tables are not affected by this change, only new tables that are created. * Some of the|InnoDB| option settings also change, so that the default configuration represents the best practices for|InnoDB| functionality,reliability, and file management: |innodb_file_format=Barracuda| rather than|Antelope|, |innodb_strict_mode=TRUE| rather than|FALSE|, and |innodb_file_per_table=TRUE| rather than|FALSE|. * The system tables remain in|MyISAM| format. *|MyISAM| remains the default storage engine for the embedded version of MySQL Bugs Fixed: * Performance: While looking for the shortest index for a covering index scan, the optimizer did not consider the full row length for a clustered primary key, as in InnoDB. Secondary covering indexes will now be preferred, making full table scans less likely. (Bug#39653:http://bugs.mysql.com/bug.php?id=39653) * Security Fix: The server failed to check the table name argument of a COM_FIELD_LIST command packet for validity and compliance to acceptable table name standards. This could be exploited to bypass almost all forms of checks for privileges and table-level grants by providing a specially crafted table name argument to COM_FIELD_LIST. In MySQL 5.0 and above, this allowed an authenticated user with SELECT privileges on one table to obtain the field definitions of any table in all other databases and potentially of other MySQL instances accessible from the server's file system. Additionally, for MySQL version 5.1 and above, an authenticated user with DELETE or SELECT privileges on one table could delete or read content from any other table in all databases on this server, and potentially of other MySQL instances accessible from the server's file system. (Bug#53371:http://bugs.mysql.com/bug.php?id=53371, CVE-2010-1848 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1848)) * Security Fix: The server was susceptible to a buffer-overflow attack due to a failure to perform bounds checking on the table name argument of a COM_FIELD_LIST command packet. By sending long data for the table name, a buffer is overflown, which could be exploited by an authenticated user to inject malicious code. (Bug#53237:http://bugs.mysql.com/bug.php?id=53237, CVE-2010-1850 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1850)) * Security Fix: Privilege checking for UNINSTALL PLUGIN was incorrect. (Bug#51770:http://bugs.mysql.com/bug.php?id=51770, CVE-2010-1621 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1621)) * Security Fix: The server could be tricked into reading packets indefinitely if it received a packet larger than the maximum size of one packet. (Bug#50974:http://bugs.mysql.com/bug.php?id=50974, CVE-2010-1849 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1849)) * Incompatible Change: TRUNCATE TABLE did not take an exclusive lock on a table if truncation was done by deleting all rows in the table. For InnoDB tables, this could break proper isolation because InnoDB ended up aborting some granted locks when truncating a table. Now an exclusive metadata lock is taken before TRUNCATE TABLE can proceed. This guarantees that no other transaction is using the table. Incompatible change: Truncation using delete no longer fails if sql_safe_updates is enabled (this was an undocumented side effect). (Bug#42643:http://bugs.mysql.com/bug.php?id=42643) * Important Change: Replication: It was possible to set sql_log_bin with session scope inside a transaction or subquery. (Bug#53437:http://bugs.mysql.com/bug.php?id=53437) * Important Change: Replication: When changing binlog_format or binlog_direct_non_transactional_updates, permissions were not checked prior to checking the scope and context of the variable being changed. As a result of this fix, an error is no longer reported when---in the context of a transaction or a stored function---you try to set a value for a session variable that is the same as its previous value, or for a variable whose scope is global only. (Bug#51277:http://bugs.mysql.com/bug.php?id=51277) * Important Change: Replication: When invoked, CHANGE MASTER TO and SET GLOBAL sql_slave_skip_counter now cause information to be written to the error log about the slave's state prior to execution of the statement. For CHANGE MASTER TO, this information includes the previous values for MASTER_HOST, MASTER_PORT, MASTER_LOG_FILE, and MASTER_LOG_POS. For SET GLOBAL sql_slave_skip_counter, this information includes the previous values of sql_slave_skip_counter, the group relay log name, and the group relay log position. (Bug#43406:http://bugs.mysql.com/bug.php?id=43406, Bug#43407:http://bugs.mysql.com/bug.php?id=43407) * Partitioning: Replication: Attempting to execute LOAD DATA on a partitioned MyISAM table while using statement-based logging mode caused the master to hang or crash. (Bug#51851:http://bugs.mysql.com/bug.php?id=51851) * Partitioning: Replication: The NO_DIR_IN_CREATE server SQL mode was not enforced when defining subpartitions. In certain cases, this could lead to failures on replication slaves. (Bug#42954:http://bugs.mysql.com/bug.php?id=42954) * Partitioning: Rows inserted into a table created using a PARTITION BY LIST COLUMNS option referencing multiple columns could be inserted into the wrong partition. (Bug#52815:http://bugs.mysql.com/bug.php?id=52815) * Partitioning: Partition pruning on RANGE partitioned tables did not always work correctly; the last partition was not excluded if the range was beyond it (when not using MAXVALUE). Now the last partition is not included if the partitioning function value is not within the range. (Bug#51830:http://bugs.mysql.com/bug.php?id=51830) * Partitioning: Attempting to partition a table using a DECIMAL column caused the server to crash; this not supported and is now specifically disallowed. Bug#51347:http://bugs.mysql.com/bug.php?id=51347) * Partitioning: ALTER TABLE statements that cause table partitions to be renamed or dropped (such as ALTER TABLE ... ADD PARTITION, ALTER TABLE ... DROP PARTITION, and ALTER TABLE ... REORGANIZE PARTITION) --- when run concurrently with queries against the INFORMATION_SCHEMA.PARTITIONS table --- could fail, cause the affected partitioned tables to become unusable, or both. This was due to the fact that the INFORMATION_SCHEMA database ignored the name lock imposed by the ALTER TABLE statement on the partitions affected. In particular, this led to problems with InnoDB tables, because InnoDB would accept the rename operation, but put it in a background queue, so that subsequent rename operations failed when InnoDB was unable to find the correct partition. Now, INFORMATION_SCHEMA honors name locks imposed by ongoing ALTER TABLE statements that cause partitions to be renamed or dropped. (Bug#50561:http://bugs.mysql.com/bug.php?id=50561) See also Bug#47343:http://bugs.mysql.com/bug.php?id=47343, Bug#45808:http://bugs.mysql.com/bug.php?id=45808. * Partitioning: The insert_id server system variable was not reset following an insert that failed on a partitioned MyISAM table having an AUTO_INCREMENT column. (Bug#50392:http://bugs.mysql.com/bug.php?id=50392) * Partitioning: Foreign keys are not supported on partitioned tables. However, it was possible via an ALTER TABLE statement to set a foreign key on a partitioned table; it was also possible to partition a table with a single foreign key. (Bug#50104:http://bugs.mysql.com/bug.php?id=50104) * Partitioning: When attempting to perform DDL on a partitioned table and the table's .par file could not be found, the server returned the inaccurate error message Out of memory; restart server and try again (needed 2 bytes). Now in such cases, the server returns the error Failed to initialize partitions from .par file. (Bug#49161:http://bugs.mysql.com/bug.php?id=49161) * Partitioning: GROUP BY queries performed poorly for some partitioned tables. This was due to the block size not being set for partitioned tables, thus the keys per block was not correct, which could cause such queries to be optimized incorrectly. (Bug#48229:http://bugs.mysql.com/bug.php?id=48229) See also Bug#37252:http://bugs.mysql.com/bug.php?id=37252. * Partitioning: REPAIR TABLE failed for partitioned ARCHIVE tables. (Bug#46565:http://bugs.mysql.com/bug.php?id=46565) * Replication: When using unique keys on NULL columns in row-based replication, the slave sometimes chose the wrong row when performing an update. This happened because a table having a unique key on such a column could have multiple rows containing NULL for the column used by the unique key, and the slave merely picked the first row containing NULL in that column. (Bug#53893:http://bugs.mysql.com/bug.php?id=53893) * Replication: When a CREATE TEMPORARY TABLE ... SELECT statement was executed within a transaction that updated only transactional engines and was later rolled back (for example, due to a deadlock) the changes---including the creation of the temporary table---were not written to the binary log, which caused subsequent updates to this table to fail on the slave. (Bug#53421:http://bugs.mysql.com/bug.php?id=53421) * Replication: When using the statement-based logging format, statements that used CONNECTION_ID() were always kept in the transaction cache; consequently, nontransactional changes that should have been flushed before the transaction were kept in the transaction cache. (Bug#53075:http://bugs.mysql.com/bug.php?id=53075) This regression was introduced by Bug#51894:http://bugs.mysql.com/bug.php?id=51894. * Replication: In some cases, attempting to update a column with a value of an incompatible type resulted in a mismatch between master and slave because the column value was set to its implicit default value on the master (as expected), but the same column on the slave was set to NULL. (Bug#52868:http://bugs.mysql.com/bug.php?id=52868) * Replication: When temporary tables were in use, switching the binary logging format from STATEMENT to ROW did not take effect until all temporary tables were dropped. (The existence of temporary tables should prevent switching the format only from ROW to STATEMENT from taking effect, not the reverse.) (Bug#52616:http://bugs.mysql.com/bug.php?id=52616) * Replication: A buffer overrun in the handling of DATE column values could cause mysqlbinlog to fail when reading back logs containing certain combinations of DML on a table having a DATE column followed by dropping the table. (Bug#52202:http://bugs.mysql.com/bug.php?id=52202) * Replication: The failure of a REVOKE statement was logged with the wrong error code, causing replication slaves to stop even when the failure was expected on the master. (Bug#51987:http://bugs.mysql.com/bug.php?id=51987) * -laio missing from embedded libs (Bug#55215:_http://bugs.mysql.com/bug.php?id=55215_) Please see the complete list of changes to MySQL 5.5.5 at_http://dev.mysql.com/doc/refman/5.5/en/news-5-5-5.html_ Thanks Sunanda (MySQL Release Engineering Team)