Dear MySQL users,

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


Enjoy!

=======================================================================

C.1.1. Changes in MySQL 5.1.40

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 S/390, PowerPC and generic ia64.

For further details on the InnoDB Plugin see

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-38.html


 Bugs fixed:

   * Incompatible Change: In binary installations of MySQL, the
     supplied binary-configure script would start and configure
     MySQL, even when request help on the command with the --help
     command-line option. The --help, if provided, will no longer
     start and install the server.
     (Bug#30954: http://bugs.mysql.com/30954)

   * Partitioning: When reorganizing partitions, not all affected
     subpartitions were removed prior to renaming. One way in which
     the issue was visible was that attempting to reorganize two
     partitions into a single partition having the same name as one
     of the original partitions could lead to a crash of the
     server. (Bug#47029: http://bugs.mysql.com/47029)
     See also Bug#45961: http://bugs.mysql.com/45961,
     Bug#43729: http://bugs.mysql.com/43729.

   * Partitioning: An online or fast ALTER TABLE of a partitioned
     table could leave behind temporary files in the database
     directory. (Bug#46483: http://bugs.mysql.com/46483)

   * Partitioning: When performing an INSERT ... SELECT into a
     partitioned table, read_buffer_size bytes of memory were
     allocated for every partition in the target table, resulting
     in consumption of large amounts of memory when the table had
     many partitions (more than 100).
     This fix changes the method used to estimate the buffer size
     required for each partition and limits the total buffer size
     to a maximum of approximately 10 times read_buffer_size.
     (Bug#45840: http://bugs.mysql.com/45840)

   * Partitioning: Inserting negative values into an AUTO_INCREMENT
     column of a partitioned table could lead to apparently
     unrelated errors or a crash of the server.
     (Bug#45823: http://bugs.mysql.com/45823)

   * Partitioning: Unnecessary calls were made in the server code
     for performing bulk inserts on partitions for which no inserts
     needed to be made. (Bug#35845: http://bugs.mysql.com/35845)
     See also Bug#35843: http://bugs.mysql.com/35843.

   * Replication: Performing ALTER TABLE ... DISABLE KEYS on a
     slave table caused row-based replication to fail.
     (Bug#47312: http://bugs.mysql.com/47312)

   * Replication: BEGIN statements were not included in the output
     of mysqlbinlog. (Bug#46998: http://bugs.mysql.com/46998)

   * Replication: When using row-based replication, importing a
     dump made with mysqldump and replicating a row with an
     AUTO_INCREMENT column set to 0, with NO_AUTO_VALUE_ON_ZERO
     active on the master, the row was inserted successfully on the
     master; however any setting for NO_AUTO_VALUE_ON_ZERO was
     ignored on the slave. When the AUTO_INCREMENT column was
     incremented, this caused replication to fail on the slave due
     to a duplicate key error. In some cases it could also cause
     the slave to crash. (Bug#45999: http://bugs.mysql.com/45999)

   * Replication: Concurrent transactions that inserted rows into a
     table with an AUTO_INCREMENT column could break
     statement-based or mixed-format replication error 1062
     Duplicate entry '...' for key 'PRIMARY' on the slave. This was
     especially likely to happen when one of the transactions
     activated a trigger that inserted rows into the table with the
     AUTO_INCREMENT column, although other conditions could also
     cause the issue to manifest.
     (Bug#45677: http://bugs.mysql.com/45677)

   * Replication: By default, all statements executed by the
     mysql_upgrade program on the master are written to the binary
     log, then replicated to the slave. In some cases, this can
     result in problems; for example, it attempted to alter log
     tables on replicated databases (this failed due to logging
     being enabled).
     As part of this fix, a new mysql_upgrade option --write-binlog
     is added. Its inverse, --skip-write-binlog, can be used to
     disable binary logging while the upgrade is in progress.
     (Bug#43579: http://bugs.mysql.com/43579)

   * Replication: On the master, if a binary log event is larger
     than max_allowed_packet, the error message
     ER_MASTER_FATAL_ERROR_READING_BINLOG is sent to a slave when
     it requests a dump from the master, thus leading the I/O
     thread to stop. On a slave, the I/O thread stops when
     receiving a packet larger than max_allowed_packet.
     In both cases, however, there was no Last_IO_Error reported,
     which made it difficult to determine why the slave had stopped
     in such cases. Now, Last_IO_Error is reported when
     max_allowed_packet is exceeded, and provides the reason for
     which the slave I/O thread stopped.
     (Bug#42914: http://bugs.mysql.com/42914)
     See also Bug#14068: http://bugs.mysql.com/14068,
     Bug#47200: http://bugs.mysql.com/47200,
     Bug#47303: http://bugs.mysql.com/47303.

   * API: The fix for Bug#24507: http://bugs.mysql.com/24507 could
     lead in some cases to client application failures due to a
     race condition. Now the server waits for the "dummy" thread to
     return before exiting, thus making sure that only one thread
     can initialize the POSIX threads library.
     (Bug#42850: http://bugs.mysql.com/42850)

   * The pthread_cond_wait() implementations for Windows could
     deadlock in some rare circumstances.
     (Bug#47768: http://bugs.mysql.com/47768)

   * Solaris binary packages now are compiled with -g0 rather than
     -g. (Bug#47137: http://bugs.mysql.com/47137)

   * EXPLAIN caused a server crash for certain valid queries.
     (Bug#47106: http://bugs.mysql.com/47106)

   * The configure option --without-server did not work.
     (Bug#46980: http://bugs.mysql.com/46980)

   * Failed multiple-table DELETE statements could raise an
     assertion. (Bug#46958: http://bugs.mysql.com/46958)

   * When creating a new instance on Windows using mysqld-nt and
     the --install parameter, the value of the service would be set
     incorrectly, resulting in a failure to start the configured
     service. (Bug#46917: http://bugs.mysql.com/46917)

   * The server crashed when re-using outer column references in
     correlated subqueries when the enclosing query used a temp
     table. (Bug#46791: http://bugs.mysql.com/46791)

   * Assertion failure could result from repeated execution of a
     stored procedure containing an incorrect query with a
     subselect. (Bug#46629: http://bugs.mysql.com/46629)

   * The server ignored the setting of sync_frm for CREATE TABLE
     ... LIKE. (Bug#46591: http://bugs.mysql.com/46591)

   * An attempt to create a table with the same name as an existing
     view could cause a server crash.
     (Bug#46384: http://bugs.mysql.com/46384)

   * A parser problem prevented properly stripping backquotes from
    an argument to a user-defined function (UDF). If the UDF was
     in an ORDER BY clause, its name would not be properly resolved
     against an alias with the same name in the select list.
     (Bug#46259: http://bugs.mysql.com/46259)

   * Certain SELECT statements containing DISTINCT, GROUP BY, and
     HAVING clauses could hang in an infinite loop.
     (Bug#46159: http://bugs.mysql.com/46159)

   * CREATE TEMPORARY TABLE failed for InnoDB tables on systems
     with case-insensitive file systems when lower_case_table_names
     = 2 and the pathname of the temporary file directory contained
     uppercase characters. (Bug#45638: http://bugs.mysql.com/45638)

   * Appending values to an ENUM or SET definition is a metadata
     change for which ALTER TABLE need not rebuild the table, but
     it was being rebuilt anyway.
     (Bug#45567: http://bugs.mysql.com/45567)

   * The socket system variable was unavailable on Windows.
     (Bug#45498: http://bugs.mysql.com/45498)

   * When re-installing MySQL on Windows on a server that has a
     data directory from a previous MySQL installation, the
     installer would fail to identify the existence of the
     installation and the password configured for the root user.
     (Bug#45200: http://bugs.mysql.com/45200)

   * Client flags were incorrectly initialized for the embedded
     server, causing several tests in the jp test suite to fail.
     (Bug#45159: http://bugs.mysql.com/45159)

   * SELECT ... WHERE ... IN (NULL, ...) was executed using a full
     table scan, even if the same query without the NULL used an
     efficient range scan. (Bug#44139: http://bugs.mysql.com/44139)
     See also Bug#18360: http://bugs.mysql.com/18360.

   * LOAD DATA INFILE statements were written to the binary log in
     such a way that parsing problems could occur when re-executing
     the statement from the log.
     (Bug#43746: http://bugs.mysql.com/43746)

   * Selecting from the process list in the embedded server caused
     a crash. (Bug#43733: http://bugs.mysql.com/43733)

   * Attempts to enable large_pages with a shared memory segment
     larger than 4GB caused a server crash.
     (Bug#43606: http://bugs.mysql.com/43606)

   * A test for stack growth failed on some platforms, leading to
     server crashes. (Bug#42213: http://bugs.mysql.com/42213)

   * The mysql-stress-test.pl test script was missing from the
     noinstall packages on Windows.
     (Bug#41546: http://bugs.mysql.com/41546)

   * Privileges for SHOW CREATE VIEW were not being checked
     correctly. (Bug#35996: http://bugs.mysql.com/35996)

   * Different invocations of CHECKSUM TABLE could return different
     results for a table containing columns with spatial data
     types. (Bug#35570: http://bugs.mysql.com/35570)

   * myisamchk performed parameter value casting at startup that
     generated unnecessary warning messages.
     (Bug#33785: http://bugs.mysql.com/33785)

   * When building MySQL on Windows from source, the
     WITH_BERKELEY_STORAGE_ENGINE option would fail to configure
     BDB support correctly.
     (Bug#27693: http://bugs.mysql.com/27693)


Thanks,
MySQL RE Team

Hery Ramilison, Karen Langford, MySQL Release Engineers
Database Group, Sun Microsystem Inc.





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