InnoDB Plugin Notes:
        This release includes InnoDB Plugin 1.0.6.
        This version is considered of Release Candidate (RC) quality.
      
        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:
Replication: 
        Introduced the
        --binlog-direct-non-transactional-updates
        server option. This option causes updates using the
        statement-based logging format to tables using nontransactional
        engines to be written directly to the binary log, rather than to
        the transaction cache.
      
        Before using this option, be certain that you have no
        dependencies between transactional and nontransactional tables.
        A statement that both selects from an
        InnoDB table and inserts into a
        MyISAM table is an example of such
        a dependency. For more information, see
        Section 16.1.3.4, “Binary Log Options and Variables”.
       (Bug#46364)
Bugs fixed:
Performance: 
        The method for comparing INFORMATION_SCHEMA
        names and database names was nonoptimal and an improvement was
        made: When the database name length is already known, a length
        check is made first and content comparison skipped if the
        lengths are unequal.
       (Bug#49501)
Performance: 
        The MD5() and
        SHA1() functions had excessive
        overhead for short strings.
       (Bug#49491)
Partitioning: 
        When an ALTER TABLE
        ... REORGANIZE PARTITION statement on an
        InnoDB table failed due to
        innodb_lock_wait_timeout
        expiring while waiting for a lock, InnoDB did
        not clean up any temporary files or tables which it had created.
        Attempting to reissue the ALTER
        TABLE statement following the timeout could lead to
        storage engine errors, or possibly a crash of the server.
       (Bug#47343)
Replication: In some cases, inserting into a table with many columns could cause the binary log to become corrupted. (Bug#50018)
See also Bug#42749.
Replication: 
        When using row-based replication, setting a
        BIT or
        CHAR column of a
        MyISAM table to
        NULL, then trying to delete from the table,
        caused the slave to fail with the error Can't find
        record in table.
       (Bug#49481, Bug#49482)
Replication: 
        When logging in row-based mode, DDL statements are actually
        logged as statements; however, statements that affected
        temporary tables and followed DDL statements failed to reset the
        binary log format to ROW, with the result
        that these statements were logged using the statement-based
        format. Now the state of
        binlog_format is restored after
        a DDL statement has been written to the binary log.
       (Bug#49132)
Replication: 
        When using row-based logging, the statement
        CREATE TABLE t IF
        NOT EXIST ... SELECT was logged as
        CREATE TEMPORARY
        TABLE t IF NOT EXIST ... SELECT when
        t already existed as a temporary table. This
        was caused by the fact that the temporary table was opened and
        the results of the SELECT were
        inserted into it when a temporary table existed and had the same
        name.
      
        Now, when this statement is executed, t is
        created as a base table, the results of the
        SELECT are inserted into it
        — even if there already exists a temporary table having
        the same name — and the statement is logged correctly.
       (Bug#47418)
See also Bug#47442.
Replication: 
        Due to a change in the size of event representations in the
        binary log, when replicating from a MySQL 4.1 master to a slave
        running MySQL 5.0.60 or later, the
        START SLAVE
        UNTIL statement did not function correctly, stopping
        at the wrong position in the log. Now the slave detects that the
        master is using the older version of the binary log format, and
        corrects for the difference in event size, so that the slave
        stops in the correct position.
       (Bug#47142)
The SSL certificates in the test suite were about to expire. They have been updated with expiration dates in the year 2015. (Bug#50642)
        The printstack function does not exist on
        Solaris 8 or earlier, which would lead to a compilation failure.
       (Bug#50409)
        A user could see tables in
        INFORMATION_SCHEMA.TABLES without
        appropriate privileges for them.
       (Bug#50276)
Debug output for join structures was garbled. (Bug#50271)
        The filesort sorting method applied to a
        CHAR(0) column could lead to a
        server crash.
       (Bug#49897)
        sql_buffer_result had an effect
        on non-SELECT statements,
        contrary to the documentation.
       (Bug#49552)
In some cases a subquery need not be evaluated because it returns only aggregate values that can be calculated from table metadata. This sometimes was not handled by the enclosing subquery, resulting in a server crash. (Bug#49512)
Mixing full-text searches and row expressions caused a crash. (Bug#49445)
Creating or dropping a table with 1023 transactions active caused an assertion failure. (Bug#49238)
        mysql-test-run.pl now recognizes the
        MTR_TESTCASE_TIMEOUT,
        MTR_SUITE_TIMEOUT,
        MTR_SHUTDOWN_TIMEOUT, and
        MTR_START_TIMEOUT environment variables. If
        they are set, their values are used to set the
        --testcase-timeout,
        --suite-timeout,
        --shutdown-timeout, and
        --start-timeout options, respectively.
       (Bug#49210)
        If innodb_force_recovery was
        set to 4 or higher, the server could crash when opening an
        InnoDB table containing an
        auto-increment column. MySQL versions 5.1.31 and later were
        affected.
       (Bug#46193)
The optimizer could continue to execute a query after a storage engine reported an error, leading to a server crash. (Bug#46175)


User Comments
Add your own comment.