On Fri, Apr 23, 2010 at 10:03 AM, Karen Langford <karen.langf...@oracle.com> wrote: > Dear MySQL users, > > MySQL Community Server 5.1.46, a new version of the popular Open > Source Database Management System, has been released. MySQL 5.1.46 is > recommended for use on production systems. > > For an overview of what's new in MySQL 5.1, please see > > http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html > > For information on installing MySQL 5.1.46 on new servers or upgrading > to MySQL 5.1.46 from previous MySQL releases, please see > > http://dev.mysql.com/doc/refman/5.1/en/installing.html > > MySQL Server is available in source and binary form for a number of > platforms from our download pages at > > http://dev.mysql.com/downloads/ > > 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 > > For information on open issues in MySQL 5.1, please see the errata > list at > > http://dev.mysql.com/doc/refman/5.1/en/open-bugs.html > > The following section lists the changes in the MySQL source code since > the previous released version of MySQL 5.1. It may also be viewed > online at > > http://dev.mysql.com/doc/refman/5.1/en/news-5-1-46.html > > Enjoy! > > ======================================================================= > C.1.2. Changes in MySQL 5.1.46 > > InnoDB Plugin Notes: > > * InnoDB Plugin has been upgraded to version 1.0.7. This version > is considered of General Availability (GA) quality. The InnoDB > Plugin Change History > (http://www.innodb.com/doc/innodb_plugin-1.0/innodb-changes.ht > ml) may contain information in addition to those changes > reported here. > In this release, the InnoDB Plugin is included in source and > binary distributions, except RHEL3, RHEL4, SuSE 9 (x86, > x86_64, ia64), and generic Linux RPM packages. It also does > not work for FreeBSD 6 and HP-UX or for Linux on generic ia64. > > Functionality added or changed: > > * There is a new system variable, skip_name_resolve, that is set > from the value of the --skip-name-resolve server option. This > provides a way to determine at runtime whether the server uses > name resolution for client connections. > (Bug#37168: http://bugs.mysql.com/bug.php?id=37168) > > Bugs fixed: > > * Security Fix: Privilege checking for UNINSTALL PLUGIN was > incorrect. (Bug#51770: http://bugs.mysql.com/bug.php?id=51770) > > * 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: 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: 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: TRUNCATE TABLE performed on a temporary table > using the InnoDB storage engine was logged even when using > row-based mode. > (Bug#51251: http://bugs.mysql.com/bug.php?id=51251) > > * Replication: When using temporary tables the binary log needs > to insert a pseudo-thread ID for threads that are using > temporary tables, each time a switch happens between two > threads, both of which are using temporary tables. However, if > a thread issued a failing statement before exit, its ID was > not recorded in the binary log, and this in turn caused the ID > for the next thread that tried to do something with a > temporary table not to be logged as well. Subsequent replays > of the binary log failed with the error Table ... doesn't > exist. (Bug#51226: http://bugs.mysql.com/bug.php?id=51226) > > * Replication: If the master was using sql_mode='TRADITIONAL', > duplicate key errors were not sent to the slave, which > received 0 rather than the expected error code. This caused > replication to fail even when such an error was expected. > (Bug#51055: http://bugs.mysql.com/bug.php?id=51055) > > * Replication: When run with the --database option, mysqlbinlog > printed ROLLBACK statements but did not print any > corresponding SAVEPOINT statements. > (Bug#50407: http://bugs.mysql.com/bug.php?id=50407) > > * Replication: CREATE EVENT statements were padded with > "garbage" characters when written to the binary log, which > caused a syntax error when trying to read back from the log. > (Bug#50095: http://bugs.mysql.com/bug.php?id=50095) > > * Replication: Column length information generated by InnoDB did > not match that generated by MyISAM, which caused invalid > metadata to be written to the binary log when trying to > replicate BIT columns. > (Bug#49618: http://bugs.mysql.com/bug.php?id=49618) > > * Replication: The value of Slave_IO_running in the output of > SHOW SLAVE STATUS did not distinguish between all 3 possible > states of the slave I/O thread (not running; running but not > connected; connected). Now the value Connecting (rather than > No) is shown when the slave I/O thread is running but the > slave is not connected to a replication master. > The server system variable Slave_running also reflects this > change, and is now consistent with what is shown for > Slave_IO_running. > (Bug#30703: http://bugs.mysql.com/bug.php?id=30703, > Bug#41613: http://bugs.mysql.com/bug.php?id=41613, > Bug#51089: http://bugs.mysql.com/bug.php?id=51089) > > * EXPLAIN EXTENDED crashed trying to resolve references to freed > temporary table columns for GROUP_CONCAT() ORDER BY arguments. > (Bug#52397: http://bugs.mysql.com/bug.php?id=52397) > > * For InnoDB Plugin, bit fields were causing problems with > concurrency on SMP systems because of word-packing issues. > (Bug#52360: http://bugs.mysql.com/bug.php?id=52360) > > * The optimizer could attempt to evaluate the WHERE clause > before any rows had been read, resulting in a server crash. > (Bug#52177: http://bugs.mysql.com/bug.php?id=52177) > > * For LDML-defined collations, some data structures were not > initialized properly to enable UPPER() and LOWER() to work > correctly. (Bug#51976: http://bugs.mysql.com/bug.php?id=51976) > > * On Windows, LOAD_FILE() could cause a crash for some > pathnames. (Bug#51893: http://bugs.mysql.com/bug.php?id=51893) > > * Invalid memory reads occurred for HANDLER ... READ NEXT after > a failed HANDLER ... READ FIRST. > (Bug#51877: http://bugs.mysql.com/bug.php?id=51877) > > * After TRUNCATE TABLE of a MyISAM table, subsequent queries > could crash the server if myisam_use_mmap was enabled. > (Bug#51868: http://bugs.mysql.com/bug.php?id=51868) > > * If myisam_sort_buffer_size was set to a small value, table > repair for MyISAM tables with FULLTEXT indexes could crash the > server. (Bug#51866: http://bugs.mysql.com/bug.php?id=51866) > > * In LOAD DATA INFILE, using a SET clause to set a column equal > to itself caused a server crash. > (Bug#51850: http://bugs.mysql.com/bug.php?id=51850) > > * A problem with equality propagation optimization for prepared > statements and stored procedures caused a server crash upon > re-execution of the prepared statement or stored procedure. > (Bug#51650: http://bugs.mysql.com/bug.php?id=51650) > See also Bug#8115: http://bugs.mysql.com/bug.php?id=8115, > Bug#8849: http://bugs.mysql.com/bug.php?id=8849. > > * The optimizer performed an incorrect join type when COALESCE() > appeared within an IN() operation. > (Bug#51598: http://bugs.mysql.com/bug.php?id=51598) > > * The server crashed when the optimizer attempted to determine > constant tables but a table storage engine did not support > exact record count. > (Bug#51494: http://bugs.mysql.com/bug.php?id=51494) > > * The server could crash populating the > INFORMATION_SCHEMA.PROCESSLIST table due to lack of mutex > protection. > (Bug#51377: http://bugs.mysql.com/bug.php?id=51377) > > * Use of HANDLER statements with tables that had spatial indexes > caused a server crash. > (Bug#51357: http://bugs.mysql.com/bug.php?id=51357) > > * With an XA transaction active, SET autocommit = 1 could cause > side effects such as memory corruption or a server crash. > (Bug#51342: http://bugs.mysql.com/bug.php?id=51342) > > * Following a bulk insert into a MyISAM table, if MyISAM failed > to build indexes using repair by sort, data file corruption > could occur. > (Bug#51307: http://bugs.mysql.com/bug.php?id=51307) > > * CHECKSUM TABLE could compute the checksum for BIT columns > incorrectly. > (Bug#51304: http://bugs.mysql.com/bug.php?id=51304) > > * A HAVING clause on a joined table in some cases failed to > eliminate rows which should have been excluded from the result > set. (Bug#51242: http://bugs.mysql.com/bug.php?id=51242) > > * The type inference used for view columns caused some columns > in views to be handled as the wrong type, as compared to the > same columns in base tables. DATE columns in base tables were > treated as TIME columns in views, and base table TIME columns > as view DATETIME columns. > (Bug#50918: http://bugs.mysql.com/bug.php?id=50918) > > * The YEAR values 2000 and 0000 could be treated as equal. > (Bug#49910: http://bugs.mysql.com/bug.php?id=49910) > > * Performing a single in-place ALTER TABLE containing ADD INDEX > and DROP INDEX options that used the same index name could > result in a corrupt table definition file. Now such ALTER > TABLE statements are no longer performed in place. > (Bug#49838: http://bugs.mysql.com/bug.php?id=49838) > > * mysql_upgrade did not detect when CSV log tables incorrectly > contained columns that could be NULL. Now these columns are > altered to be NOT NULL. > (Bug#49823: http://bugs.mysql.com/bug.php?id=49823) > > * If a stored function contained a RETURN statement with an ENUM > value in the ucs2 character set, SHOW CREATE FUNCTION and > SELECT DTD_IDENTIFIER FROM INFORMATION_SCHEMA.ROUTINES > returned incorrect values. > (Bug#48766: http://bugs.mysql.com/bug.php?id=48766) > > * The server crashed when it could not determine the best > execution plan for queries involving outer joins with > nondeterministic ON clauses such as the ones containing the > RAND() function, a user-defined function, or a NOT > DETERMINISTIC stored function. > (Bug#48483: http://bugs.mysql.com/bug.php?id=48483) > > * A query that read from a derived table (of the form SELECT ... > FROM (SELECT ...)) produced incorrect results when the > following conditions were present: > > + The table subquery contained a derived query ((SELECT ... > ) AS column). > > + The derived query could potentially produce zero rows or > a single NULL (that is, no rows matched, or the query > used an aggregate function such as SUM() running over > zero rows). > > + The table subquery joined at least two tables. > > + The join condition involved an index. > (Bug#47904: http://bugs.mysql.com/bug.php?id=47904) > > * The optimization to read MIN() or MAX() values from an index > did not properly handle comparisons with NULL values. This > could produce incorrect results for MIN() or MAX()when the > WHERE clause tested a NOT NULL column for NULL. > (Bug#47762: http://bugs.mysql.com/bug.php?id=47762) > > * Killing a query during the optimization phase of a subquery > could cause a server crash. > (Bug#47761: http://bugs.mysql.com/bug.php?id=47761) > > * The query shown by EXPLAIN EXTENDED plus SHOW WARNINGS could > produce results different from the original query. > (Bug#47669: http://bugs.mysql.com/bug.php?id=47669) > > * Renaming a column of an InnoDB table caused the server to go > out of sync with the InnoDB data dictionary. > (Bug#47621: http://bugs.mysql.com/bug.php?id=47621) > > * MyISAM could write uninitialized data to new index pages. Now > zeros are written to unused bytes in the pages. > (Bug#47598: http://bugs.mysql.com/bug.php?id=47598) > > * Setting myisam_repair_threads larger than 1 could result in > the cardinality for all indexes of a MyISAM table being set to > 1 after parallel index repair. > (Bug#47444: http://bugs.mysql.com/bug.php?id=47444) > > * In debug builds, if the listed columns in the view definition > of the table used in an INSERT ... SELECT statement > mismatched, an assertion was raised in the query cache > invalidation code following the failing statement. > (Bug#46615: http://bugs.mysql.com/bug.php?id=46615) > > * For a query that selected from a view and used an alias for > the view, the metadata used the alias name rather than the > view name in the MYSQL_FIELD.table member. > (Bug#41788: http://bugs.mysql.com/bug.php?id=41788) > > * mysql_upgrade did not create temporary files properly. > (Bug#41057: http://bugs.mysql.com/bug.php?id=41057) > > * It was possible for DROP TABLE of one MyISAM table to remove > the data and index files of a different MyISAM table. > (Bug#40980: http://bugs.mysql.com/bug.php?id=40980) > > * If the arguments to a CONCAT() call included a local routine > variable, selecting the return value into a user variable > could produce an incorrect result. > (Bug#40625: http://bugs.mysql.com/bug.php?id=40625) > > * SHOW CREATE VIEW returned invalid SQL if the definition > contained a SELECT 'string' statement where the string was > longer than the maximum length of a column name, due to the > fact that this text was also used as an alias (in the AS > clause). > Because not all names retrieved from arbitrary SELECT > statements can be used as view column names due to length and > format restrictions, the server now checks the conformity of > automatically generated column names and rewrites according to > a predefined format any names that are not acceptable as view > column names before storing the final view definition on disk. > In such cases, the name is now rewritten as Name_exp_pos, > where pos is the position of the column. To avoid this > conversion scheme, define explicit, valid names for view > columns using the column_list clause of the CREATE VIEW > statement. > As part of this fix, aliases are now generated only for > top-level statements. > (Bug#40277: http://bugs.mysql.com/bug.php?id=40277) > > * While looking for the shortest index for a covering index > scan, the optimizer ignored that a clustered primary key read > the entire table. > (Bug#39653: http://bugs.mysql.com/bug.php?id=39653) > > * mysqlbinlog had a memory leak in its option-processing code. > (Bug#38468: http://bugs.mysql.com/bug.php?id=38468) > > * The test for readline during configuration failed when trying > to build MySQL in a directory other than the source tree root. > (Bug#35250: http://bugs.mysql.com/bug.php?id=35250) > > Thanks, > MySQL RE Team > > Hery Ramilison, Karen Langford, MySQL Release Engineers > Database Group, Oracle.
For the record I think it is really bad form that ~10 of ~50 bugs noted are non-public. This is really annoying. Trying to make judgments about risks of upgrading vs not upgrading with non-public bugs is very difficult. -- Rob Wultsch wult...@gmail.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
