← Back to team overview

ius-coredev team mailing list archive

[Bug 583957] Re: MySQL 5.1.47 Source Update

 

** Also affects: ius/mysql51
   Importance: Undecided
       Status: New

** Changed in: ius/mysql51
     Assignee: (unassigned) => BJ Dierkes (derks)

** Changed in: ius
   Importance: Undecided => Medium

** Changed in: ius
     Assignee: (unassigned) => BJ Dierkes (derks)

** Changed in: ius/mysql51
   Importance: Undecided => Medium

** Changed in: ius
    Milestone: None => mysql51-5.1.47-1

** Changed in: ius/mysql51
    Milestone: None => mysql51-5.1.47-1

-- 
MySQL 5.1.47 Source Update
https://bugs.launchpad.net/bugs/583957
You received this bug notification because you are a member of IUS Core
Development, which is subscribed to IUS Community Project.

Status in IUS Community Project: New
Status in IUS Community Project mysql51 series: New

Bug description:
Dear MySQL users,

MySQL Community Server 5.1.47, a new version of the popular Open
Source Database Management System, has been released.  MySQL 5.1.47 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.47 on new servers or upgrading
to MySQL 5.1.47 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-47.html

Enjoy!

C.1.1. Changes in MySQL 5.1.47 (06 May 2010)

   InnoDB Plugin Notes:

     * InnoDB Plugin has been upgraded to version 1.0.8. This version
       is considered of General Availability (GA) quality. InnoDB
       Plugin Change History
       (http://dev.mysql.com/doc/innodb-plugin/1.0/en/innodb-changes.
       html), 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:

     * InnoDB stores redo log records in a hash table during
       recovery. On 64-bit systems, this hash table was 1/8 of the
       buffer pool size. To reduce memory usage, the dimension of the
       hash table was reduced to 1/64 of the buffer pool size (or
       1/128 on 32-bit systems).
       (Bug#53122: http://bugs.mysql.com/bug.php?id=53122)

   Bugs fixed:

     * 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: 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))

     * 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)

     * 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)

     * Certain path names passed to LOAD_FILE() could cause a server
       crash. (Bug#53417: http://bugs.mysql.com/bug.php?id=53417)

     * When reporting a foreign key constraint violation during
       INSERT, InnoDB could display uninitialized data for the
       DB_TRX_ID and DB_ROLL_PTR system columns.
       (Bug#53202: http://bugs.mysql.com/bug.php?id=53202)

     * InnoDB page splitting could enter an infinite loop for
       compressed tables.
       (Bug#52964: http://bugs.mysql.com/bug.php?id=52964)

     * An overly strict assertion could fail during the purge of
       delete-marked records in DYNAMIC or COMPRESSED InnoDB tables
       that contain column prefix indexes.
       (Bug#52746: http://bugs.mysql.com/bug.php?id=52746)

     * InnoDB attempted to choose off-page storage without ensuring
       that there was an "off-page storage" flag in the record
       header. To correct this, in DYNAMIC and COMPRESSED formats,
       InnoDB stores locally any non-BLOB columns having a maximum
       length not exceeding 256 bytes. This is because there is no
       room for the "external storage" flag when the maximum length
       is 255 bytes or less. This restriction trivially holds in
       REDUNDANT and COMPACT formats, because there InnoDB always
       stores locally columns having a length up to local_len = 788
       bytes. (Bug#52745: http://bugs.mysql.com/bug.php?id=52745)

     * Semi-consistent read was implemented for InnoDB to address
       Bug#3300: http://bugs.mysql.com/bug.php?id=3300.
       Semi-consistent reads do not block when a nonmatching record
       is already locked by some other transaction. If the record is
       not locked, a lock is acquired, but is released if the record
       does not match the WHERE condition. However, semi-consistent
       read was attempted even for UPDATE statements having a WHERE
       condition of the form pk_col1=constant1, ...,
       pk_colN=constantN. Some code that was designed with the
       assumption that semi-consistent read would be only attempted
       on table scans, failed.
       (Bug#52663: http://bugs.mysql.com/bug.php?id=52663)

     * Setting @@GLOBAL.debug to an empty string failed to clear the
       current debug settings.
       (Bug#52629: http://bugs.mysql.com/bug.php?id=52629)

     * A memory leak occurred due to missing deallocation of the
       comparators array (a member of the Arg_comparator class).
       (Bug#52124: http://bugs.mysql.com/bug.php?id=52124)

     * For debug builds, creating a view containing a subquery that
       might require collation adjustment caused an assertion to be
       raised. For example, this could occur if some items had
       different collations but the result collation could be
       adjusted to the one of them.
       (Bug#52120: http://bugs.mysql.com/bug.php?id=52120)

     * Connections waiting for an InnoDB row lock ignored KILL until
       the row lock wait ended. Now, KILL during lock wait results in
       "query interrupted" instead of "lock wait timeout exceeded".
       (Bug#51920: http://bugs.mysql.com/bug.php?id=51920)

     * Locking involving the LOCK_plugin,
       LOCK_global_system_variables, and LOCK_status mutexes could
       deadlock. (Bug#51591: http://bugs.mysql.com/bug.php?id=51591)

     * InnoDB fast index creation could incorrectly use a table copy
       in some cases.
       (Bug#50946: http://bugs.mysql.com/bug.php?id=50946)

     * A syntactically invalid trigger could cause the server to
       crash when trying to list triggers.
       (Bug#50755: http://bugs.mysql.com/bug.php?id=50755)

     * InnoDB Plugin checks to see whether a row could possibly
       exceed the maximum size if all columns are fully used. This
       produced Row size too large errors for some tables that could
       be created with the built-in InnoDB. Now the check is only
       done when innodb_strict_mode is enabled or if the table is
       dynamic or compressed.
       (Bug#50495: http://bugs.mysql.com/bug.php?id=50495)

     * In MySQL 5.1, READ COMMITTED was changed to use less locking
       due to the availability of row based binary logging (see the
       Note under READ COMMITTED at Section 12.3.6, "SET TRANSACTION
       Syntax"). However, READ UNCOMMITTED did not have the same
       change, so it was using more locks than the higher isolation
       level, which is unexpected. This was changed so that READ
       UNCOMMITTED now also uses the lesser amount of locking and has
       the same restrictions for binary logging.
       (Bug#48607: http://bugs.mysql.com/bug.php?id=48607)

     * EXPLAIN could cause a server crash for some queries with
       subqueries.
       (Bug#48419: http://bugs.mysql.com/bug.php?id=48419)

     * On Windows, the server failed to find a description for Event
       ID 100. (Bug#48042: http://bugs.mysql.com/bug.php?id=48042)

     * For updates to InnoDB tables, TIMESTAMP columns could be
       updated even when no values actually changed.
       (Bug#47453: http://bugs.mysql.com/bug.php?id=47453)

     * If the server is started with --skip-grant-tables, plugin
       loading and unloading should be disallowed, but the server
       failed to reject INSTALL PLUGIN and UNINSTALL PLUGIN
       statements.
       (Bug#46261: http://bugs.mysql.com/bug.php?id=46261)

     * Storage engine plugins on Windows could've been built with a
       definition of time_t which was different from the server
       expectations. The difference could cause affected plugins to
       crash. In addition, the use of the time_t type in the storage
       engine API layer has been enforced.
       (Bug#39802: http://bugs.mysql.com/bug.php?id=39802,
       Bug#40092: http://bugs.mysql.com/bug.php?id=40092)

     * When using UNINSTALL PLUGIN to remove a loaded plugin, open
       tables and connections caused mysqld to hang until the open
       connections had been closed.
       (Bug#39053: http://bugs.mysql.com/bug.php?id=39053)

     * 1) In rare cases, if a thread was interrupted during a FLUSH
       PRIVILEGES operation, a debug assertion occurred later due to
       improper diagnostic area setup. 2) A KILL operation could
       cause a console error message referring to a diagnostic area
       state without first ensuring that the state existed.
       (Bug#33982: http://bugs.mysql.com/bug.php?id=33982)


Thanks,
MySQL RE Team

Hery Ramilison, Karen Langford, MySQL Release Engineers
Database Group, Oracle.





References