Dear MySQL users, We are proud to present to you the MySQL Server 5.1.24-rc release, a new "release candidate" version of the popular open source database.
Bear in mind that this is still a "candidate" release, and as with any other pre-production release, caution should be taken when installing on production level systems or systems with critical data. For production level systems using 5.0, we would like to direct your attention to the product description of MySQL Enterprise at: http://mysql.com/products/enterprise/ The MySQL 5.1.24-rc release is now available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/ and mirror sites. Note that 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. Please also note that some of our mirrors are currently experiencing problems that may result in serving corrupted files. We are working with the mirror maintainers to resolve this. We welcome and appreciate your feedback, bug reports, bug fixes, patches etc.: http://forge.mysql.com/wiki/Contributing The description of the changes from version 5.1.23-rc to this 5.1.24-rc is some 1,800 lines long, that is about 96 kB. As some mail systems are bound to truncate long mail at 64 kB, I split the announcement into two parts - this is part 1 only. The following section lists the (first part of the) changes from version to version in the MySQL source code since the latest released version of MySQL 5.1, the MySQL 5.1.23-rc release. It can also be viewed online at http://dev.mysql.com/doc/refman/5.1/en/news-5-1-24.html Sincerely, Kent Boortz The MySQL build team at Sun Microsystems ============================================================================== Functionality added or changed: * Please note that the Federated engine is not built into the MySQL 5.1.24 RC release binaries, but is scheduled to return in the next release, which will be MySQL 5.1.25. The reasons for Federated's omission in 5.1.24 RC includes various quality and timing issues that unfortunately could not be avoided, and we apologize for any inconvenience this has caused. * Windows Installer: Important Change: The data directory now defaults to the Windows Common App Data Folder (on Windows XP, this is ...\All Users\Application Data; on Vista, it is ProgramData). (Bug#34593: http://bugs.mysql.com/34593) * Cluster API: Important Change: Because NDB_LE_MemoryUsage.page_size_kb shows memory page sizes in bytes rather than kilobytes, it has been renamed to page_size_bytes. The name page_size_kb is now deprecated and thus subject to removal in a future release, although it currently remains supported for reasons of backwards compatibility. See The Ndb_logevent_type Type (http://dev.mysql.com/doc/ndbapi/en/ndb-logevent-type.html), for more information about NDB_LE_MemoryUsage. (Bug#30271: http://bugs.mysql.com/30271) * Replication: Introduced the slave_exec_mode system variable to control whether idempotent or strict mode is used for replication conflict resolution. Idempotent mode suppresses duplicate-key, no-key-found, and some other errors, and is needed for circular replication, multi-master replication, and some other complex replication setups when using MySQL Cluster. Strict mode is the default. (Bug#31609: http://bugs.mysql.com/31609) * Replication: When running the server with --binlog-format=MIXED or --binlog-format=STATEMENT, a query that referred to a system variable used the slave's value when replayed on the slave. This meant that, if the value of a system variable was inserted into a table, the slave differed from the master. Now, statements that refer to a system variable are marked as "unsafe", which means that: + When the server is using --binlog-format=MIXED, the row-based format is used automatically to replicate these statements. + When the server is using --binlog-format=STATEMENT, these statements produce a warning. (Bug#31168: http://bugs.mysql.com/31168) See also Bug#34732: http://bugs.mysql.com/34732 * The ndbd and ndb_mgmd manpages have been reclassified from volume 1 to volume 8. (Bug#34642: http://bugs.mysql.com/34642) * For binary .tar.gz packages, mysqld and other binaries now are compiled with debugging symbols included to enable easier use with a debugger. (Bug#33252: http://bugs.mysql.com/33252) * Formerly, when the MySQL server crashed, the generated stack dump was numeric and required external tools to properly resolve the names of functions. This is not very helpful to users having a limited knowledge of debugging techniques. In addition, the generated stack trace contained only the names of functions and was formatted differently for each platform due to different stack layouts. Now it is possible to take advantage of newer versions of the GNU C Library that provide a set of functions to obtain and manipulate stack traces from within the program. On systems that use the ELF binary format, the stack trace contains important information such as the shared object where the call was generated, an offset into the function, and the actual return address. Having the function name also makes possible the name demangling of C++ functions. The library generates meaningful stack traces on the following platforms: i386, x86_64, PowerPC, IA64, Alpha, and S390. On other platforms, a numeric stack trace is still produced, and the use of the resolve_stack_dump utility is still required. (Bug#31891: http://bugs.mysql.com/31891) * mysqltest now has mkdir and rmdir commands for creating and removing directories. (Bug#31004: http://bugs.mysql.com/31004) * The server uses less memory when loading privileges containing table grants. (Patch provided by Google.) (Bug#25175: http://bugs.mysql.com/25175) * Added the Uptime_since_flush_status status variable, which indicates the number of seconds since the most recent FLUSH STATUS statement. (From Jeremy Cole) (Bug#24822: http://bugs.mysql.com/24822) * Potential memory leaks in SHOW PROFILE were eliminated. (Bug#24795: http://bugs.mysql.com/24795) * SHOW OPEN TABLES now supports FROM and LIKE clauses. (Bug#12183: http://bugs.mysql.com/12183) * Formerly it was possible to specify an innodb_flush_method value of fdatasync to obtain the default flush behavior of using fdatasync() for flushing. This is no longer possible because it can be confusing that a value of fdatasync causes use of fsync() rather than fdatasync(). * The use of InnoDB hash indexes now can be controlled by setting the new innodb_adaptive_hash_index system variable at server startup. By default, this variable is enabled. See Section 13.5.13.3, "Adaptive Hash Indexes." ============================================================================== Errata in this release: The Configuration Wizard for Windows has a few known problems which will be fixed in the following release: * The Configuration Wizard may report an error when changing the root password; however, the password will be changed. The warning pop-up may be hidden behind the active window. * The Configuration Wizard may report [Internal error 2739]. A workaround for this failure is described here: http://blogs.msdn.com/astebner/archive/2007/06/07/3151752.aspx ============================================================================== Bugs fixed: * Important Change: Security Fix: It was possible to circumvent privileges through the creation of MyISAM tables employing the DATA DIRECTORY and INDEX DIRECTORY options to overwrite existing table files in the MySQL data directory. Use of the MySQL data directory in DATA DIRECTORY and INDEX DIRECTORY is now disallowed. This is now also true of these options when used with partitioned tables and individual partitions of such tables. (Bug#32167: http://bugs.mysql.com/32167) * Partitioning: Incompatible Change: The following statements did not function correctly with corrupted or crashed tables and have been removed: + ALTER TABLE ... ANALYZE PARTITION + ALTER TABLE ... CHECK PARTITION + ALTER TABLE ... OPTIMIZE PARTITION + ALTER TABLE ... REPAIR PARTITION ALTER TABLE ... REBUILD PARTITION is unaffected by this change and continues to be available. This statement and ALTER TABLE ... REORGANIZE PARTITION may be used to analyze and optimize partitioned tables, since these operations cause the partition files to be rebuilt. In addition, it remains possible to use mysqlcheck on partitioned tables and myisamchk on partitioned MyISAM tables. (Bug#20129: http://bugs.mysql.com/20129) * Incompatible Change: In MySQL 5.1.23, the last_errno and last_error members of the NET structure in mysql_com.h were renamed to client_last_errno and client_last_error. This was found to cause problems for connectors that use the internal NET structure for error handling. The change has been reverted. (Bug#34655: http://bugs.mysql.com/34655) See also Bug#12713: http://bugs.mysql.com/12713 * Important Change: Replication: When the master crashed during an update on a transactional table while in AUTOCOMMIT mode, the slave failed. This fix causes every transaction (including AUTOCOMMIT transactions) to be recorded in the binlog as starting with a BEGIN and ending with a COMMIT or ROLLBACK. (Bug#26395: http://bugs.mysql.com/26395) * Disk Data: Important Change: It is no longer possible on 32-bit systems to issue statements appearing to create Disk Data log files or data files greater than 4 GB in size. (Trying to create log files or data files larger than 4 GB on 32-bit systems led to unrecoverable data node failures; such statements now fail with NDB error 1515.) (Bug#29186: http://bugs.mysql.com/29186) * Important Change: It was possible to use FRAC_SECOND as a synonym for MICROSECOND with DATE_ADD(), DATE_SUB(), and INTERVAL; now, using FRAC_SECOND with anything other than TIMESTAMPADD() or TIMESTAMPDIFF() produces a syntax error. It is now possible (and preferable) to use MICROSECOND with TIMESTAMPADD() and TIMESTAMPDIFF(), and FRAC_SECOND is now deprecated. (Bug#33834: http://bugs.mysql.com/33834) * Important Change: InnoDB free space information is now shown in the Data_free column of SHOW TABLE STATUS and in the DATA_FREE column of the INFORMATION_SCHEMA.TABLES table. (Bug#32440: http://bugs.mysql.com/32440) This regression was introduced by Bug#11379: http://bugs.mysql.com/11379 * Important Change: The server handled truncation of values having excess trailing spaces into CHAR, VARCHAR, and TEXT columns in different ways. This behavior has now been made consistent for columns of all three of these types, and now follows the existing behavior of VARCHAR columns in this regard; that is, a Note is always issued whenever such truncation occurs. This change does not affect columns of these three types when using a binary encoding; BLOB columns are also unaffected by the change, since they always use a binary encoding. (Bug#30059: http://bugs.mysql.com/30059) * Important Change: An AFTER UPDATE trigger was not invoked when the UPDATE did not make any changes to the table for which the trigger was defined. Now AFTER UPDATE triggers behave the same in this regard as do BEFORE UPDATE triggers, which are invoked whether the UPDATE makes any changes in the table or not. (Bug#23771: http://bugs.mysql.com/23771) * Partitioning: MySQL Cluster: When partition pruning on an NDB table resulted in an ordered index scan spanning only one partition, any descending flag for the scan was wrongly discarded, causing ORDER BY DESC to be treated as ORDER BY ASC, MAX() to be handled incorrectly, and similar problems. (Bug#33061: http://bugs.mysql.com/33061) * MySQL Cluster: Upgrades of a cluster using while a DataMemory setting in excess of 16 GB caused data nodes to fail. (Bug#34378: http://bugs.mysql.com/34378) * MySQL Cluster: Performing many SQL statements on NDB tables while in AUTOCOMMIT mode caused a memory leak in mysqld. (Bug#34275: http://bugs.mysql.com/34275) * MySQL Cluster: In certain rare circumstances, a race condition could occur between an aborted insert and a delete leading a data node crash. (Bug#34260: http://bugs.mysql.com/34260) * MySQL Cluster: Multi-table updates using ordered indexes during handling of node failures could cause other data nodes to fail. (Bug#34216: http://bugs.mysql.com/34216) * MySQL Cluster: When configured with NDB support, MySQL failed to compile using gcc 4.3 on 64bit FreeBSD systems. (Bug#34169: http://bugs.mysql.com/34169) * MySQL Cluster: The failure of a DDL statement could sometimes lead to node failures when attempting to execute subsequent DDL statements. (Bug#34160: http://bugs.mysql.com/34160) * MySQL Cluster: Extremely long SELECT statements (where the text of the statement was in excess of 50000 characters) against NDB tables returned empty results. (Bug#34107: http://bugs.mysql.com/34107) * MySQL Cluster: When configured with NDB support, MySQL failed to compile on 64bit FreeBSD systems. (Bug#34046: http://bugs.mysql.com/34046) See also Bug#32175: http://bugs.mysql.com/32175 * MySQL Cluster: High numbers of insert operations, delete operations, or both could cause NDB error 899 (Rowid already allocated) to occur unnecessarily. (Bug#34033: http://bugs.mysql.com/34033) * MySQL Cluster: A periodic failure to flush the send buffer by the NDB TCP transporter could cause an unnecessary delay of 10 ms between operations. (Bug#34005: http://bugs.mysql.com/34005) * MySQL Cluster: A race condition could occur (very rarely) when the release of a GCI was followed by a data node failure. (Bug#33793: http://bugs.mysql.com/33793) * MySQL Cluster: Some tuple scans caused the wrong memory page to be accessed, leading to invalid results. This issue could affect both in-memory and Disk Data tables. (Bug#33739: http://bugs.mysql.com/33739) * MySQL Cluster: Statements executing multiple inserts performed poorly on NDB tables having AUTO_INCREMENT columns. (Bug#33534: http://bugs.mysql.com/33534) * MySQL Cluster: When all data and SQL nodes in the cluster were shut down abnormally (that is, other than by using STOP in the cluster management client), ndb_mgm used excessive amounts of CPU. (Bug#33237: http://bugs.mysql.com/33237) * MySQL Cluster: The ndb_waiter utility polled ndb_mgmd excessively when obtaining the status of cluster data nodes. (Bug#32025: http://bugs.mysql.com/32025) See also Bug#32023: http://bugs.mysql.com/32023 * MySQL Cluster: Transaction atomicity was sometimes not preserved between reads and inserts under high loads. (Bug#31477: http://bugs.mysql.com/31477) * MySQL Cluster: Numerous NDBCLUSTER test failures occurred in builds compiled using icc on IA64 platforms. (Bug#31239: http://bugs.mysql.com/31239) * MySQL Cluster: The server failed to reject properly the creation of an NDB table having an unindexed AUTO_INCREMENT column. (Bug#30417: http://bugs.mysql.com/30417) * MySQL Cluster: Having tables with a great many columns could cause Cluster backups to fail. (Bug#30172: http://bugs.mysql.com/30172) * MySQL Cluster: Issuing an INSERT ... ON DUPLICATE KEY UPDATE concurrently with or following a TRUNCATE statement on an NDB table failed with NDB error 4350 Transaction already aborted. (Bug#29851: http://bugs.mysql.com/29851) * MySQL Cluster: The Cluster backup process could not detect when there was no more disk space and instead continued to run until killed manually. Now the backup fails with an appropriate error when disk space is exhausted. (Bug#28647: http://bugs.mysql.com/28647) * MySQL Cluster: It was possible in config.ini to define cluster nodes having node IDs greater than the maximum allowed value. (Bug#28298: http://bugs.mysql.com/28298) * MySQL Cluster: CREATE TABLE and ALTER TABLE statements using ENGINE=NDB or ENGINE=NDBCLUSTER caused mysqld to fail on Solaris 10 for x86 platforms. (Bug#19911: http://bugs.mysql.com/19911) * Partitioning: In some cases, matching rows from a partitioned MyISAM using a BIT column as the primary key were not found by queries. (Bug#34358: http://bugs.mysql.com/34358) * Partitioning: Enabling innodb_file_per_table produced problems with partitioning and tablespace operations on partitioned InnoDB tables, in some cases leading to corrupt partitions or causing the server to crash. (Bug#33429: http://bugs.mysql.com/33429) * Partitioning: A table defined using PARTITION BY KEY and having a BIT column referenced in the partitioning key did not behave correctly; some rows could be inserted into the wrong partition, causing wrong results to be returned from queries. (Bug#33379: http://bugs.mysql.com/33379) * Partitioning: When ALTER TABLE DROP PARTITION was executed on a table on which there was a trigger, the statement failed with an error. This occurred even if the trigger did not reference any tables. (Bug#32943: http://bugs.mysql.com/32943) * Partitioning: Currently, all partitions of a partitioned table must use the same storage engine. One may optinally specify the storage engine on a per-partition basis; however, where this is the done, the storage engine must be the same as used by the table as a whole. ALTER TABLE did not enforce these rules correctly, the result being that incaccurate error messages were shown when trying to use the statement to change the storage engine used by an individual partition or partitions. (Bug#31931: http://bugs.mysql.com/31931) * Partitioning: Using the DATA DIRECTORY and INDEX DIRECTORY options for partitions with CREATE TABLE or ALTER TABLE statements appeared to work on Windows, although they are not supported by MySQL on Windows systems, and subsequent attempts to use the tables referenced caused errors. Now these options are disabled on Windows, and attempting to use them generates a warning. (Bug#30459: http://bugs.mysql.com/30459) * Replication: INSERT_ID was not written to the binary log for inserts into BLACKHOLE tables. (Bug#35178: http://bugs.mysql.com/35178) * Replication: When using statement-based replication and a DELETE, UPDATE, or INSERT ... SELECT statement using a LIMIT clause is encountered, a warning that the statement is not safe to replicate in statement mode is now issued; when using MIXED mode, the statement is now replicated using the row-based format. (Bug#34768: http://bugs.mysql.com/34768) * Replication: mysqlbinlog did not output the values of auto_increment_increment and auto_increment_offset when both were equal to their default values (for both of these variables, the default is 1). This meant that a binary log recorded by a client using the defaults for both variables and then replayed on another client using its own values for either or both of these variables produced erroneous results. (Bug#34732: http://bugs.mysql.com/34732) See also Bug#31168: http://bugs.mysql.com/31168 * Replication: When the Windows version of mysqlbinlog read 4.1 binlogs containing LOAD DATA INFILE statements, it output backslashes as path separators, causing problems for client programs expecting forward slashes. In such cases, it now converts \\ to / in directory paths. (Bug#34355: http://bugs.mysql.com/34355) * Replication: SHOW SLAVE STATUS failed when slave I/O was about to terminate. (Bug#34305: http://bugs.mysql.com/34305) * Replication: The character sets and collations used for constant identifiers in stored procedures were not replicated correctly. (Bug#34289: http://bugs.mysql.com/34289) * Replication: mysqlbinlog from a 5.1 or later MySQL distribution could not read binary logs generated by a 4.1 server when the logs contained LOAD DATA INFILE statements. (Bug#34141: http://bugs.mysql.com/34141) This regression was introduced by Bug#32407: http://bugs.mysql.com/32407 * Replication: A CREATE USER, DROP USER, or RENAME USER statement that fails on the master, or that is a duplicate of any of these statements, is no longer written to the binlog; previously, either of these occurrences could cause the slave to fail. (Bug#33862: http://bugs.mysql.com/33862) See also Bug#29749: http://bugs.mysql.com/29749 * Replication: SHOW BINLOG EVENTS could fail when the binlog contained one or more events whose size was close to the value of max_allowed_packet. (Bug#33413: http://bugs.mysql.com/33413) * Replication: An extraneous ROLLBACK statement was written to the binary log by a connection that did not use any transactional tables. (Bug#33329: http://bugs.mysql.com/33329) * Replication: mysqlbinlog failed to release all of its memory after terminating abnormally. (Bug#33247: http://bugs.mysql.com/33247) * Replication: When a stored routine or trigger, running on a master that used MySQL 5.0 or MySQL 5.1.11 or earlier, performed an insert on an AUTO_INCREMENT column, the INSERT_ID value was not replicated correctly to a slave running MySQL 5.1.12 or later (including any MySQL 6.0 release). (Bug#33029: http://bugs.mysql.com/33029) See also Bug#19630: http://bugs.mysql.com/19630 * Replication: The error message generated due to lack of a default value for an extra column was not sufficiently informative. (Bug#32971: http://bugs.mysql.com/32971) * Replication: When a user variable was used inside an INSERT statement, the corresponding binlog event was not written to the binlog correctly. (Bug#32580: http://bugs.mysql.com/32580) * Replication: When using row-based replication, deletes from a table with a foreign key constraint failed on the slave. (Bug#32468: http://bugs.mysql.com/32468) * Replication: The --base64-output option for mysqlbinlog was not honored for all types of events. This interfered in some cases with performing point-in-time recovery. (Bug#32407: http://bugs.mysql.com/32407) * Replication: SQL statements containing comments using -- syntax were not replayable by mysqlbinlog, even though such statements replicated correctly. (Bug#32205: http://bugs.mysql.com/32205) * Replication: When using row-based replication from a master running MySQL 5.1.21 or earlier to a slave running 5.1.22 or later, updates of integer columns failed on the slave with Error in Unknown event: row application failed. (Bug#31583: http://bugs.mysql.com/31583) This regression was introduced by Bug#21842: http://bugs.mysql.com/21842 * Replication: Replicating write, update, or delete events from a master running MySQL 5.1.15 or earlier to a slave running 5.1.16 or later caused the slave to crash. (Bug#31581: http://bugs.mysql.com/31581) * Replication: When using row-based replication, the slave stopped when attempting to delete non-existent rows from a slave table without a primary key. In addition, no error was reported when this occurred. (Bug#31552: http://bugs.mysql.com/31552) * Replication: Errors due to server ID conflicts were reported only in the slave's error log; now these errors are also shown in the Server_IO_State column in the output of SHOW SLAVE STATUS. (Bug#31316: http://bugs.mysql.com/31316) * Replication: STOP SLAVE did not stop connection attempts properly. If the IO slave thread was attempting to connect, STOP SLAVE waited for the attempt to finish, sometimes for a long period of time, rather than stopping the slave immediately. (Bug#31024: http://bugs.mysql.com/31024) See also Bug#30932: http://bugs.mysql.com/30932 * Replication: Issuing a DROP VIEW statement caused replication to fail if the view did not actually exist. (Bug#30998: http://bugs.mysql.com/30998) * Replication: The effects of scheduled events were not always correctly reproduced on the slave when using row-based replication. (Bug#29020: http://bugs.mysql.com/29020) * Replication: Setting server_id did not update its value for the current session. (Bug#28908: http://bugs.mysql.com/28908) * Replication: Slaves running MySQL 5.1.18 and later could not read binary logs from older versions of the server. (Bug#27779: http://bugs.mysql.com/27779, Bug#32434: http://bugs.mysql.com/32434) This regression was introduced by Bug#22583: http://bugs.mysql.com/22583 * Replication: MASTER_POS_WAIT() did not return NULL when the server was not a slave. (Bug#26622: http://bugs.mysql.com/26622) * Replication: Network timeouts between the master and the slave could result in corruption of the relay log. (Bug#26489: http://bugs.mysql.com/26489) * Replication: The inspecific error message Wrong parameters to function register_slave resulted when START SLAVE failed to register on the master due to excess length of any the slave server options --report-host, --report-user, or --report-password. An error message specific to each of these options is now returned in such cases. The new error messages are: + Failed to register slave: too long 'report-host' + Failed to register slave: too long 'report-user' + Failed to register slave; too long 'report-password' (Bug#22989: http://bugs.mysql.com/22989) See also Bug#19328: http://bugs.mysql.com/19328 * Replication: START SLAVE UNTIL MASTER_LOG_POS=position issued on a slave that was using --log-slave-updates and that was involved in circular replication would cause the slave to run and stop one event later than that specified by the value of position. (Bug#13861: http://bugs.mysql.com/13861) * Replication: PURGE BINARY LOGS TO and PURGE BINARY LOGS BEFORE did not handle missing binary log files correctly or in the same way. Now for both of these statements, if any files listed in the .index file are missing from the filesystem, the statement fails with an error. * Cluster Replication: Disk Data: Statements violating unique keys on Disk Data tables (such as attempting to insert NULL into a NOT NULL column) could cause data nodes to fail. When the statement was executed from the binlog, this could also result in failure of the slave cluster. (Bug#34118: http://bugs.mysql.com/34118) * Disk Data: Updating in-memory columns of one or more rows of Disk Data table, followed by deletion of these rows and re-insertion of them, caused data node failures. (Bug#33619: http://bugs.mysql.com/33619) * Cluster Replication: Setting --replicate-ignore-db=mysql caused the mysql.ndb_apply_status table not to be replicated, breaking Cluster Replication. (Bug#28170: http://bugs.mysql.com/28170) * Cluster API: When reading a BIT(64) value using NdbOperation:getValue(), 12 bytes were written to the buffer rather than the expected 8 bytes. (Bug#33750: http://bugs.mysql.com/33750) * Binary log purging caused an assertion failure if a binary log file could not be deleted (such as when the name actually referred to a directory). (Bug#35676: http://bugs.mysql.com/35676) * Manually replacing a binary log file with a directory having the same name caused an error that was not handled correctly. (Bug#35675: http://bugs.mysql.com/35675) * Using LOAD DATA INFILE with a view could crash the server. (Bug#35469: http://bugs.mysql.com/35469) * Selecting from INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS could cause a server crash. (Bug#35406: http://bugs.mysql.com/35406) See also Bug#35108: http://bugs.mysql.com/35108 * For a TERMPORARY table, DELETE with no WHERE clause could fail when preceded by DELETE statements with a WHERE clause. (Bug#35392: http://bugs.mysql.com/35392) * If the server crashes with an InnoDB error due to unavailability of undo slots and the used slots are not used during rollback, the error could persist when the server is restarted. (Bug#35352: http://bugs.mysql.com/35352) * In some cases, when too many clients tried to connect to the server, the proper SQLSTATE code was not returned. (Bug#35289: http://bugs.mysql.com/35289) * For InnoDB tables, ALTER TABLE DROP failed if the name of the column to be dropped began with "foreign". (Bug#35220: http://bugs.mysql.com/35220) * Queries could return different results depending on whether ORDER BY columns were indexed. (Bug#35206: http://bugs.mysql.com/35206) * When a view containing a reference to DUAL was created, the reference was removed when the definition was stored, causing some queries against the view to fail with invalid SQL syntax errors. (Bug#35193: http://bugs.mysql.com/35193) * SELECT ... FROM INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS caused the server to crash if the table referenced by a foreign key had been dropped. This issue was observed on Windows platforms only. (Bug#35108: http://bugs.mysql.com/35108) See also Bug#35406: http://bugs.mysql.com/35406 * Non-connection threads were being counted in the value of the Max_used_connections status variable. (Bug#35074: http://bugs.mysql.com/35074) * A query that performed a ref_or_null join where the second table used a key having one or columns that could be NULL and had a column value that was NULL caused the server to crash. (Bug#34945: http://bugs.mysql.com/34945) This regression was introduced by Bug#12144: http://bugs.mysql.com/12144 * For some queries, the optimizer used an ordered index scan for GROUP BY or DISTINCT when it was supposed to use a loose index scan, leading to incorrect results. (Bug#34928: http://bugs.mysql.com/34928) (Continues in part 2 of this announcement) -- Kent Boortz, Senior Production Engineer Sun Microsystems Office: +46 19 182931 Mobile: +46 70 2791171 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
