List:General Discussion« Previous MessageNext Message »
From:Karen Langford Date:November 18 2009 6:36pm
Subject:MySQL Community Server 5.1.41 has been released
View as plain text  
Dear MySQL users,

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

Enjoy!

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

C.1.1. Changes in MySQL 5.1.41

  Functionality added or changed:

    * In the default operation of the InnoDB buffer pool, a block is
      loaded at the midpoint for the first access and then moved
      immediately to the head of the list as soon as another access
      occurs. In the case of a table scan (such as performed for a
      mysqldump operation), each block read by the scan ends up
      moving to the head of the list because multiple rows are
      accessed from each block. This occurs even for a one-time
      scan, where the blocks are not otherwise used by other
      queries. Blocks may also be loaded by the read-ahead
      background thread and then moved to the head of the new
      sublist by a single access. These effects are disadvantageous
      because they push blocks that are in heavy use by other
      queries out of the new sublist to the old sublist where they
      become subject to eviction.
      InnoDB Plugin now provides two system variables that enable
      LRU algorithm tuning:

         + innodb_old_blocks_pct
           Specifies the approximate percentage of the buffer pool
           used for the old block sublist. The range of values is 5
           to 95. The default value is 37 (that is, 3/8 of the
           pool).

         + innodb_old_blocks_time
           Specifies how long in milliseconds (ms) a block inserted
           into the old sublist must stay there before it can be
           moved to the new sublist. The default value is 0, so
           after a block is inserted into the old sublist, it moves
           immediately to the new sublist the next time it is
           accessed, no matter how soon after insertion the next
           access occurs. If the value is greater than 0, blocks
           remain in the old sublist until an access occurs at least
           that many ms after initial insertion. For example, a
           value of 1000 causes blocks to stay in the old sublist
           for 1 second before moving to the new sublist.
      For additional information, see Section 7.4.6, "The InnoDB
      Buffer Pool." (Bug#45015: http://bugs.mysql.com/45015)

    * For InnoDB Plugin, two new status variables have been added to
      SHOW STATUS output. Innodb_buffer_pool_read_ahead and
      Innodb_buffer_pool_read_ahead_evicted indicate the number of
      pages read in by the InnoDB read-ahead background thread, and
      the number of such pages evicted without ever being accessed,
      respectively. Also, the status variables
      Innodb_buffer_pool_read_ahead_rnd and
      Innodb_buffer_pool_read_ahead_seq status variables have been
      removed.
      The built-in version of InnoDB is not affected by these
      changes. (Bug#42885: http://bugs.mysql.com/42885)

    * InnoDB Plugin has been upgraded to version 1.0.5. This version
      is considered of Release Candidate (RC) quality.

    * The server now supports a Debug Sync facility for thread
      synchronization during testing and debugging. To compile in
      this facility, configure MySQL with the --enable-debug-sync
      option. The debug_sync system variable provides the user
      interface Debug Sync. mysqld and mysql-test-run.pl support a
      --debug-sync-timeout option to enable the facility and set the
      default synchronization point timeout.

  Bugs fixed:

    * Partitioning: An ALTER TABLE ... ADD PARTITION statement that
      caused open_files_limit to be exceeded led to a crash of the
      MySQL server. (Bug#46922: http://bugs.mysql.com/46922)
      See also Bug#47343: http://bugs.mysql.com/47343.

    * Partitioning: The cardinality of indexes on partitioned tables
      was calculated using the first partition in the table, which
      could result in suboptimal query execution plans being chosen.
      Now the partition having the most records is used instead,
      which should result in better use of indexes and thus improved
      performance of queries against partitioned tables in many if
      not most cases. (Bug#44059: http://bugs.mysql.com/44059)

    * Replication: When using statement-based or mixed-format
      replication, the database name was not written to the binary
      log when executing a LOAD DATA statement. This caused problems
      when the table being loaded belonged to a database other than
      the current database; data could be loaded into the wrong
      table (if a table having the same name existed in the current
      database) or replication could fail (if no table having that
      name existed in the current database). Now a table referenced
      in a LOAD DATA statement is always logged using its fully
      qualified name when the database to which it belongs is not
      the current database.
      This issue occurred in MySQL 5.1.40 only.
      (Bug#48297: http://bugs.mysql.com/48297)

    * Replication: When a session was closed on the master,
      temporary tables belonging to that session were logged with
      the wrong database names when either of the following
      conditions was true:

        1. The length of the name of the database to which the
           temporary table belonged was greater than the length of
           the current database name.

        2. The current database was not set.
      (Bug#48216: http://bugs.mysql.com/48216)
      See also Bug#46861: http://bugs.mysql.com/46861,
      Bug#48297: http://bugs.mysql.com/48297.

    * Replication: When using row-based replication, changes to
      non-transactional tables that occurred early in a transaction
      were not immediately flushed upon committing a statement. This
      behavior could break consistency since changes made to
      non-transactional tables become immediately visible to other
      connections. (Bug#47678: http://bugs.mysql.com/47678)
      See also Bug#47287: http://bugs.mysql.com/47287,
      Bug#46864: http://bugs.mysql.com/46864,
      Bug#43929: http://bugs.mysql.com/43929,
      Bug#46129: http://bugs.mysql.com/46129.

    * Replication: When mysqlbinlog --verbose was used to read a
      binary log that had been recorded using the row-based format,
      the output for events that updated some but not all columns of
      tables was not correct.
      (Bug#47323: http://bugs.mysql.com/47323)

    * Replication: When using the row-based format to replicate a
      transaction involving both transactional and non-transactional
      engines, which contained a DML statement affecting multiple
      rows, the statement failed; if this transaction was followed
      by a COMMIT, the master and the slave could diverge, because
      the statement was correctly rolled back on the master, but was
      applied on the slave. (Bug#47287: http://bugs.mysql.com/47287)
      See also Bug#46864: http://bugs.mysql.com/46864.

    * Replication: A problem with the BINLOG statement in the output
      of mysqlbinlog could break replication; statements could be
      logged with the server ID stored within events by the BINLOG
      statement rather than the ID of the running server. With this
      fix, the server ID of the server executing the statements can
      no longer be overridden by the server ID stored in the binary
      log's format description statement.
      (Bug#46640: http://bugs.mysql.com/46640)
      This regression was introduced by
      Bug#32407: http://bugs.mysql.com/32407.

    * Replication: When using statement-based replication and the
      transaction isolation level was set to READ COMMITTED or a
      less strict level, InnoDB returned an error even if the
      statement in question was filtered out according to the
      --binlog-do-db or --binlog-ignore-db rules in effect at the
      time. (Bug#42829: http://bugs.mysql.com/42829)

    * Replication: FLUSH LOGS did not actually close and reopen the
      binary log index file.
      (Bug#34582: http://bugs.mysql.com/34582)

    * A build configured using the --without-server option did not
      compile the yaSSL code, so if --with-ssl was also used, the
      build failed. (Bug#47957: http://bugs.mysql.com/47957)

    * mysys/mf_keycache.c requires threading, but no test was made
      for thread support. (Bug#47923: http://bugs.mysql.com/47923)

    * The mysys/mf_strip.c file, which defines the strip_sp has been
      removed from the MySQL source. The function was no longer in
      use within the main build, and the supplied function was
      causing symbol errors on Windows builds.
      (Bug#47857: http://bugs.mysql.com/47857)

    * The Windows build for MySQL would compile the split.c and
      debug.c files unnecessarily, causing additional symbols to be
      included in mysqld. (Bug#47850: http://bugs.mysql.com/47850)

    * When building storage engines on Windows it was not possible
      to specify additional libraries within the CMake file required
      for the build. An ${engine}_LIBS macro has been added to the
      files to support these additional storage-engine specific
      libraries. (Bug#47797: http://bugs.mysql.com/47797)

    * When building a pluggable storage engine on Windows, the
      engine name could be based on the directory name where the
      engine was located, rather than the configured storage engine
      name. (Bug#47795: http://bugs.mysql.com/47795)

    * On Windows, when an idle named pipe connection was forcibly
      closed with a KILL statement or because the server was being
      shut down, the thread that was closing the connection would
      hang infinitely. (Bug#47571: http://bugs.mysql.com/47571,
      Bug#31621: http://bugs.mysql.com/31621)

    * A simple SELECT with implicit grouping could return many rows
      rather than a single row if the query was ordered by the
      aggregated column in the select list.
      (Bug#47280: http://bugs.mysql.com/47280)

    * An assertion could be raised for CREATE TABLE if there was a
      pending INSERT DELAYED or REPLACE DELAYED for the same table.
      (Bug#47274: http://bugs.mysql.com/47274)

    * Incorrect handling of predicates involving NULL by the range
      optimizer could lead to to an infinite loop during query
      execution. (Bug#47123: http://bugs.mysql.com/47123)

    * Repair by sort or parallel repair of MyISAM tables could fail
      to fail over to repair with key cache.
      (Bug#47073: http://bugs.mysql.com/47073)

    * If InnoDB reached its limit on the number of concurrent
      transactions (1023), it wrote a descriptive message to the
      error log but returned a misleading error message to the
      client, or an assertion failure occurred.
      (Bug#46672: http://bugs.mysql.com/46672)
      See also Bug#18828: http://bugs.mysql.com/18828.

    * Concurrent INSERT INTO ... SELECT statements for an InnoDB
      table could cause an AUTO_INCREMENT assertion failure.
      (Bug#46650: http://bugs.mysql.com/46650)

    * Trailing spaces were not ignored for user-defined collations
      that mapped spaces to a character other than 0x20.
      (Bug#46448: http://bugs.mysql.com/46448)
      See also Bug#29468: http://bugs.mysql.com/29468.

    * The GPL and commercial license headers had different sizes, so
      that error log, backtrace, core dump, and cluster trace file
      line numbers could be off by one if they were not checked
      against the version of the source used for the build. (For
      example, checking a GPL build backtrace against commercial
      sources.) (Bug#46216: http://bugs.mysql.com/46216)

    * InnoDB did not disallow creation of an index with the name
      GEN_CLUST_INDEX, which is used internally.
      (Bug#46000: http://bugs.mysql.com/46000)

    * During the build of the Red Hat IA64 MySQL server RPM, the
      system library link order was incorrect. This made the
      resulting Red Hat IA64 RPM depend on
      "libc.so.6.1(GLIBC_PRIVATE)(64bit)", thus preventing
      installation of the package.
      (Bug#45706: http://bugs.mysql.com/45706)

    * With InnoDB Plugin, renaming a table column and then creating
      an index on the renamed column caused a server crash to to the
      .frm file and the InnoDB data directory going out of sync. Now
      InnoDB Plugin 1.0.5 returns an error instead: ERROR 1034
      (HY000): Incorrect key file for table 'tbl_name'; try to
      repair it. To work around the problem, create another table
      with the same structure and copy the original table to it.
      (Bug#44571: http://bugs.mysql.com/44571)

    * An InnoDB error message incorrectly referred to the
      nonexistent innodb_max_files_open variable rather than to
      innodb_open_files. (Bug#44338: http://bugs.mysql.com/44338)

    * The FORCE INDEX FOR ORDER BY index hint was ignored when join
      buffering was used. (Bug#43029: http://bugs.mysql.com/43029)

    * Incorrect handling of range predicates combined with OR
      operators could yield incorrect results.
      (Bug#42846: http://bugs.mysql.com/42846)

    * Failure to treat BIT values as unsigned could lead to
      unpredictable results.
      (Bug#42803: http://bugs.mysql.com/42803)

    * Previously, InnoDB performed REPLACE INTO T SELECT ... FROM S
      WHERE ... by setting shared next-key locks on rows from S. Now
      InnoDB selects rows from from S with shared locks or as a
      consistent read, as for INSERT ... SELECT. This reduces lock
      contention between sessions.
      (Bug#37232: http://bugs.mysql.com/37232)

    * When an InnoDB tablespace filled up, an error was logged to
      the client, but not to the error log. Also, the error message
      was misleading and did not indicate the real source of the
      problem. (Bug#31183: http://bugs.mysql.com/31183)

    * In mysql, using Control-C to kill the current query resulted
      in a ERROR 1053 (08S01): Server shutdown in progress" message
      if the query was waiting for a lock.
      (Bug#28141: http://bugs.mysql.com/28141)


Thanks,
MySQL RE Team

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


Thread
MySQL Community Server 5.1.41 has been releasedKaren Langford18 Nov