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

Reply via email to