Dear MySQL users,

We are proud to present to you the MySQL Server 5.1.23-rc release,
a new "release candidate" version of the popular open source database.

Bear in mind that this is still a "candidate" release, and as with any
other pre-production release, caution should be taken when installing on
production level systems or systems with critical data. For production
level systems using 5.0, we would like to direct your attention to the
product description of MySQL Enterprise at:

            http://mysql.com/products/enterprise/

The MySQL 5.1.23-rc release is now available in source and binary form
for a number of platforms from our download pages at

            http://dev.mysql.com/downloads/

and mirror sites. Note that 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.

Please also note that some of our mirrors are currently experiencing
problems that may result in serving corrupted files. We are working with
the mirror maintainers to resolve this.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches etc.:

            http://forge.mysql.com/wiki/Contributing

The description of the changes from version 5.1.22-rc to this 5.1.23-rc
is some 1,800 lines long, that is about 96 kB. As some mail systems are
bound to truncate long mail at 64 kB, I split the announcement into two
parts - this is part 1 only.

The following section lists the (first part of the) changes from version
to version in the MySQL source code since the latest released version of
MySQL 5.1, the MySQL 5.1.22-rc release. It can also be viewed online at

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


Functionality added or changed:
  * Important Change: Partitioning: Security Fix: It was
    possible, by creating a partitioned table using the DATA
    DIRECTORY and INDEX DIRECTORY options to gain privileges
    on other tables having the same name as the partitioned
    table. As a result of this fix, any table-level DATA
    DIRECTORY or INDEX DIRECTORY options are now ignored for
    partitioned tables.
    (Bug#32091: http://bugs.mysql.com/32091, CVE-2007-5970
    (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5970))
    See also Bug#29325: http://bugs.mysql.com/29325,
    Bug#32111: http://bugs.mysql.com/32111
  * Incompatible Change: In MySQL 5.1.6, when log tables were
    implemented, the default log destination for the general
    query and slow query log was TABLE. This default has been
    changed to FILE, which is compatible with MySQL 5.0, but
    incompatible with earlier releases of MySQL 5.1 from
    5.1.6 to 5.1.20. If you are upgrading from MySQL 5.0 to
    this release, no logging option changes should be
    necessary. However, if you are upgrading from 5.1.6
    through 5.1.20 to this release and were using TABLE
    logging, use the --log-output=TABLE option explicitly to
    preserve your server's table-logging behavior.
    In MySQL 5.1.x, this bug was addressed twice because it
    turned out that the default was set in two places, only
    one of which was fixed the first time.
    (Bug#29993: http://bugs.mysql.com/29993)
  * Incompatible Change
    The parser accepted statements that contained /* ... */
    that were not properly closed with */, such as SELECT 1
    /* + 2. Statements that contain unclosed /*-comments now
    are rejected with a syntax error.
    This fix has the potential to cause incompatibilities.
    Because of Bug#26302: http://bugs.mysql.com/26302, which
    caused the trailing */ to be truncated from comments in
    views, stored routines, triggers, and events, it is
    possible that objects of those types may have been stored
    with definitions that now will be rejected as
    syntactically invalid. Such objects should be dropped and
    re-created so that their definitions do not contain
    truncated comments.
    (Bug#28779: http://bugs.mysql.com/28779)
  * MySQL Cluster: The following improvements have been made
    in the ndb_size.pl utility:
       + The script can now be used with multiple databases;
         lists of databases and tables can also be excluded
         from analysis.
       + Schema name information has been added to index
         table calculations.
       + The database name is now an optional parameter, the
         exclusion of which causes all databases to be
         examined.
       + If selecting from INFORMATION_SCHEMA fails, the
         script now attempts to fall back to SHOW TABLES.
       + A --real_table_name option has been added; this
         designates a table to handle unique index size
         calculations.
       + The report title has been amended to cover cases
         where more than one database is being analyzed.
    Support for a --socket option was also added.
    For more information, see Section 15.9.15, "ndb_size.pl
    --- NDBCluster Size Requirement Estimator."
    (Bug#28683: http://bugs.mysql.com/28683,
    Bug#28253: http://bugs.mysql.com/28253)
  * MySQL Cluster: Mapping of NDB error codes to MySQL
    storage engine error codes has been improved.
    (Bug#28423: http://bugs.mysql.com/28423)
  * MySQL Cluster: The output from the cluster management
    client showing the progress of data node starts has been
    improved. (Bug#23354: http://bugs.mysql.com/23354)
  * Partitioning: Error messages for partitioning syntax
    errors have been made more descriptive.
    (Bug#29368: http://bugs.mysql.com/29368)
  * Replication: Replication of the following now switches to
    row-based logging in MIXED mode, and generates a warning
    in STATEMENT mode:
       + USER()
       + CURRENT_USER()
       + CURRENT_USER
       + FOUND_ROWS()
       + ROW_COUNT()
    See Section 5.2.4.3, "Mixed Binary Logging (MBL) Format,"
    for more information.
    (Bug#12092: http://bugs.mysql.com/12092,
    Bug#28086: http://bugs.mysql.com/28086,
    Bug#30244: http://bugs.mysql.com/30244)
  * mysqltest now has a change_user command to change the
    user for the current connection. (It invokes the
    mysql_change_user() C API function.)
    (Bug#31608: http://bugs.mysql.com/31608)
  * mysql-test-run.pl now allows a suite name prefix to be
    specified in command-line arguments that name test cases.
    The test name syntax now is
    [suite_name.]test_name[.suffix]. For example,
    mysql-test-run.pl binlog.mytest runs the mytest.test test
    in the binlog test suite.
    (Bug#31400: http://bugs.mysql.com/31400)
  * The --event-scheduler option without a value disabled the
    event scheduler. Now it enables the event scheduler.
    (Bug#31332: http://bugs.mysql.com/31332)
  * mysqldump produces a -- Dump completed on DATE comment at
    the end of the dump if --comments is given. The date
    causes dump files for identical data take at different
    times to appear to be different. The new options
    --dump-date and --skip-dump-date control whether the date
    is added to the comment. --skip-dump-date suppresses date
    printing. The default is --dump-date (include the date in
    the comment). (Bug#31077: http://bugs.mysql.com/31077)
  * Server parser performance was improved for expression
    parsing by lowering the number of state transitions and
    reductions needed.
    (Bug#30625: http://bugs.mysql.com/30625)
  * Server parser performance was improved for identifier
    lists, expression lists, and UDF expression lists.
    (Bug#30333: http://bugs.mysql.com/30333)
  * Server parser performance was improved for boolean
    expressions. (Bug#30237: http://bugs.mysql.com/30237)
  * The LAST_EXECUTED column of the INFORMATION_SCHEMA.EVENTS
    table now indicates when the event started executing
    rather than when it finished executing. As a result, the
    ENDS column is never less than LAST_EXECUTED.
    (Bug#29830: http://bugs.mysql.com/29830)
  * The mysql_odbc_escape_string() C API function has been
    removed. It has multi-byte character escaping issues,
    doesn't honor the NO_BACKSLASH_ESCAPES SQL mode and is
    not needed anymore by Connector/ODBC as of 3.51.17.
    (Bug#29592: http://bugs.mysql.com/29592)
  * If a MyISAM table is created with no DATA DIRECTORY
    option, the .MYD file is created in the database
    directory. By default, if MyISAM finds an existing .MYD
    file in this case, it overwrites it. The same applies to
    .MYI files for tables created with no INDEX DIRECTORY
    option. To suppress this behavior, start the server with
    the new --keep_files_on_create option, in which case
    MyISAM will not overwrite existing files and returns an
    error instead. (Bug#29325: http://bugs.mysql.com/29325)
  * The default value of the connect_timeout system variable
    was increased from 5 to 10 seconds. This might help in
    cases where clients frequently encounter errors of the
    form Lost connection to MySQL server at 'XXX', system
    error: errno. (Bug#28359: http://bugs.mysql.com/28359)
  * MySQL now can be compiled with gcc 4.2.x. There was a
    problem involving a conflict with the min() and max()
    macros in my_global.h.
    (Bug#28184: http://bugs.mysql.com/28184)

Bugs fixed:
  * Security Fix: Replication: It was possible for any
    connected user to issue a BINLOG statement, which could
    be used to escalate privileges.
    Use of the BINLOG statement now requires the SUPER
    privilege. (Bug#31611: http://bugs.mysql.com/31611,
    CVE-2007-6313
    (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6
    313))
  * Security Fix: Three vulnerabilities in yaSSL versions
    1.7.5 and earlier were discovered that could lead to a
    server crash or execution of unauthorized code. The
    exploit requires a server with yaSSL enabled and TCP/IP
    connections enabled, but does not require valid MySQL
    account credentials. The exploit does not apply to
    OpenSSL.
    Note
       The proof-of-concept exploit is freely available on the
       Internet. Everyone with a vulnerable MySQL configuration
       is advised to upgrade immediately.
       (Bug#33814: http://bugs.mysql.com/33814, CVE-2008-0226
       (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0226),
       CVE-2008-0227
       (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0227))
  * Security Fix: Using RENAME TABLE against a table with
    explicit DATA DIRECTORY and INDEX DIRECTORY options can
    be used to overwrite system table information by
    replacing the symbolic link points. the file to which the
    symlink points.
    MySQL will now return an error when the file to which the
    symlink points already exists.
    (Bug#32111: http://bugs.mysql.com/32111, CVE-2007-5969
    (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5969))
  * Security Fix: ALTER VIEW retained the original DEFINER
    value, even when altered by another user, which could
    allow that user to gain the access rights of the view.
    Now ALTER VIEW is allowed only to the original definer or
    users with the SUPER privilege.
    (Bug#29908: http://bugs.mysql.com/29908)
  * Security Fix: When using a FEDERATED table, the local
    server could be forced to crash if the remote server
    returned a result with fewer columns than expected.
    (Bug#29801: http://bugs.mysql.com/29801)
  * Security Enhancement: It was possible to force an error
    message of excessive length which could lead to a buffer
    overflow. This has been made no longer possible as a
    security precaution.
    (Bug#32707: http://bugs.mysql.com/32707)
  * Important Change: Incompatible Change: A number of
    problems existed in the implementation of MERGE tables
    that could cause problems. The problems are summarized
    below:
       + Bug#26379: http://bugs.mysql.com/26379 - Combination
         of FLUSH TABLE and REPAIR TABLE corrupts a MERGE
         table. This was caused in a number of situations:
           1. A thread trying to lock a MERGE table performs
              busy waiting while REPAIR TABLE or a similar
              table administration task is ongoing on one or
              more of its MyISAM tables.
           2. A thread trying to lock a MERGE table performs
              busy waiting until all threads that did REPAIR
              TABLE or similar table administration tasks on
              one or more of its MyISAM tables in LOCK TABLES
              segments do UNLOCK TABLES. The difference
              against problem #1 is that the busy waiting
              takes place after the administration task. It
              is terminated by UNLOCK TABLES only.
           3. Two FLUSH TABLES within a LOCK TABLES segment
              can invalidate the lock. This does not require
              a MERGE table. The first FLUSH TABLES can be
              replaced by any statement that requires other
              threads to reopen the table. In 5.0 and 5.1 a
              single FLUSH TABLES can provoke the problem.
       + Bug#26867: http://bugs.mysql.com/26867 -
         Simultaneously executing LOCK TABLES and REPAIR
         TABLE on a MERGE table would result in memory/cpu
         hogging.
         Trying DML on a MERGE table, which has a child
         locked and repaired by another thread, made an
         infinite loop in the server.
       + Bug#26377: http://bugs.mysql.com/26377 - Deadlock
         with MERGE and FLUSH TABLE
         Locking a MERGE table and its children in
         parent-child order and flushing the child deadlocked
         the server.
       + Bug#25038: http://bugs.mysql.com/25038 - Waiting
         TRUNCATE
         Truncating a MERGE child, while the MERGE table was
         in use, let the truncate fail instead of waiting for
         the table to become free.
       + Bug#25700: http://bugs.mysql.com/25700 - MERGE base
         tables get corrupted by OPTIMIZE/ANALYZE/REPAIR
         TABLE
         Repairing a child of an open MERGE table corrupted
         the child. It was necessary to FLUSH the child
         first.
       + Bug#30275: http://bugs.mysql.com/30275 - MERGE
         tables: FLUSH TABLES or UNLOCK TABLES causes server
         to crash.
         Flushing and optimizing locked MERGE children
         crashed the server.
       + Bug#19627: http://bugs.mysql.com/19627 - temporary
         merge table locking
         Use of a temporary MERGE table with non-temporary
         children could corrupt the children.
         Temporary tables are never locked. Creation of
         tables with non-temporary children of a temporary
         MERGE table is now prohibited.
       + Bug#27660: http://bugs.mysql.com/27660 - Falcon:
         MERGE table possible
         It was possible to create a MERGE table with
         non-MyISAM children.
       + Bug#30273: http://bugs.mysql.com/30273 - MERGE
         tables: Can't lock file (errno: 155)
         This was a Windows-only bug. Table administration
         statements sometimes failed with "Can't lock file
         (errno: 155)".
    The fix introduces the following changes in behavior:
       + This patch changes the behavior of temporary MERGE
         tables. Temporary MERGE must have temporary
         children. The old behavior was wrong. A temporary
         table is not locked. Hence even non-temporary
         children were not locked. See
         Bug#19627: http://bugs.mysql.com/19627.
       + You cannot change the union list of a non-temporary
         MERGE table when LOCK TABLES is in effect. The
         following does not work:
         CREATE TABLE m1 ... ENGINE=MRG_MYISAM ...;
         LOCK TABLES t1 WRITE, t2 WRITE, m1 WRITE;
         ALTER TABLE m1 ... UNION=(t1,t2) ...;
         However, you can do this with a temporary MERGE
         table.
       + You cannot create a MERGE table with CREATE ...
         SELECT, neither as a temporary MERGE table, nor as a
         non-temporary MERGE table. For example:
         CREATE TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...;
         gives error message: table is not BASE TABLE.
    (Bug#19627: http://bugs.mysql.com/19627,
    Bug#25038: http://bugs.mysql.com/25038,
    Bug#25700: http://bugs.mysql.com/25700,
    Bug#26377: http://bugs.mysql.com/26377,
    Bug#26379: http://bugs.mysql.com/26379,
    Bug#26867: http://bugs.mysql.com/26867,
    Bug#27660: http://bugs.mysql.com/27660,
    Bug#30275: http://bugs.mysql.com/30275,
    Bug#30491: http://bugs.mysql.com/30491)
  * Incompatible Change: It is no longer possible to create
    CSV tables with NULL columns. However, for backwards
    compatibility, you can continue to use such tables that
    were created in previous MySQL releases.
    (Bug#32050: http://bugs.mysql.com/32050)
  * Incompatible Change: Inserting a row with a NULL value
    for a DATETIME column results in a CSV file that the
    storage engine cannot read.
    All CSV tables now need to be defined with each column
    marked as NOT NULL. An error is raised if you try to
    create a CSV table with columns that are not defined with
    NOT NULL. (Bug#31473: http://bugs.mysql.com/31473,
    Bug#32817: http://bugs.mysql.com/32817)
  * Incompatible Change: SET PASSWORD statements now cause an
    implicit commit, and thus are prohibited within stored
    functions and triggers.
    (Bug#30904: http://bugs.mysql.com/30904)
  * Incompatible Change: The mysql_install_db script could
    fail to locate some components (including resolveip)
    during execution if the --basedir option was specified on
    the command-line or within the my.cnf file. This was due
    to a conflict when comparing the compiled-in values and
    the supplied values.
    The --source-install command-line option to the script
    has been removed and replaced with the --srcdir option.
    mysql_install_db now locates components either using the
    compiled-in options, the --basedir option or --srcdir
    option. (Bug#30759: http://bugs.mysql.com/30759)
  * Incompatible Change: Within a stored routine, it is no
    longer allowable to declare a cursor for a SHOW
    statement. This happened to work in some instances, but
    is no longer supported.
    (Bug#29223: http://bugs.mysql.com/29223)
  * Incompatible Change: GRANT and REVOKE statements now
    cause an implicit commit, and thus are prohibited within
    stored functions and triggers.
    (Bug#21975: http://bugs.mysql.com/21975,
    Bug#21422: http://bugs.mysql.com/21422,
    Bug#17244: http://bugs.mysql.com/17244)
  * Incompatible Change: It was possible for option files to
    be read twice at program startup, if some of the standard
    option file locations turned out to be the same
    directory. Now duplicates are removed from the list of
    files to be read.
    Also, users could not override system-wide settings using
    ~/.my.cnf because SYSCONFDIR/my.cnf was read last. The
    latter file now is read earlier so that ~/.my.cnf can
    override system-wide settings.
    (Bug#20748: http://bugs.mysql.com/20748)
  * Important Change: MySQL Cluster: AUTO_INCREMENT columns
    had the following problems when used in NDB tables:
       + The AUTO_INCREMENT counter was not updated correctly
         when such a column was updated.
       + AUTO_INCREMENT values were not prefetched beyond
         statement boundaries.
       + AUTO_INCREMENT values were not handled correctly
         with INSERT IGNORE statements.
       + After being set, ndb_autoincrement_prefetch_sz
         showed a value of 1, regardless of the value it had
         actually been set to.
    As part of this fix, the behavior of
    ndb_autoincrement_prefetch_sz has changed. Setting this
    to less than 32 no longer has any effect on prefetching
    within statements (where IDs are now always obtained in
    batches of 32 or more), but only between statements. The
    default value for this variable has also changed, and is
    now 1. (Bug#25176: http://bugs.mysql.com/25176,
    Bug#31956: http://bugs.mysql.com/31956,
    Bug#32055: http://bugs.mysql.com/32055)
  * Partitioning: Important Note: An apostrophe or single
    quote character (') used in the DATA DIRECTORY, INDEX
    DIRECTORY, or COMMENT for a PARTITION clause caused the
    server to crash. When used as part of a CREATE TABLE
    statement, the crash was immediate. When used in an ALTER
    TABLE statement, the crash did not occur until trying to
    perform a SELECT or DML statement on the table. In either
    case, the server could not be completely restarted until
    the .FRM file corresponding to the newly created or
    altered table was deleted.
    Note
       Upgrading to the current (or later) release solves this
       problem only for tables that are newly created or
       altered. Tables created or altered in previous versions
       of the server to include ' characters in PARTITION
       options must still be removed by deleting the
       corresponding .FRM files and re-creating them afterwards.
       (Bug#30695: http://bugs.mysql.com/30695)
  * Important Note: The RENAME DATABASE statement was removed
    and replaced with ALTER DATABASE db_name UPGRADE DATA
    DIRECTORY NAME. The RENAME DATABASE statement was
    intended for upgrading database directory names to the
    encoding format used in 5.1 for representing identifiers
    in the filesystem (see Section 7.2.3, "Mapping of
    Identifiers to Filenames"). However, the statement was
    found to be dangerous because it could result in loss of
    database contents. See Section 11.1.18, "RENAME DATABASE
    Syntax" and Section 11.1.1, "ALTER DATABASE Syntax."
    (Bug#17565: http://bugs.mysql.com/17565,
    Bug#21741: http://bugs.mysql.com/21741,
    Bug#28360: http://bugs.mysql.com/28360)
  * Replication: MySQL Cluster: Row-based replication from or
    to a big-endian machine where the table used the NDB
    storage engine failed, if the same table on the other
    machine was either non-NDB or the other machine was
    little-endian. (Bug#29549: http://bugs.mysql.com/29549,
    Bug#30790: http://bugs.mysql.com/30790)
    See also Bug#24231: http://bugs.mysql.com/24231,
    Bug#30024: http://bugs.mysql.com/30024,
    Bug#30133: http://bugs.mysql.com/30133,
    Bug#30134: http://bugs.mysql.com/30134
  * MySQL Cluster: An improperly reset internal signal was
    observed as a hang when using events in the NDB API but
    could result in various errors.
    (Bug#33206: http://bugs.mysql.com/33206)
  * MySQL Cluster: Incorrectly handled parameters could lead
    to a crash in the Transaction Coordinator during a node
    failure, causing other data nodes to fail.
    (Bug#33168: http://bugs.mysql.com/33168)
  * MySQL Cluster: A memory leak occurred if a subscription
    start request was received by the subscription manager
    before the node making the request was fully connected to
    the cluster. (Bug#32652: http://bugs.mysql.com/32652)
  * MySQL Cluster: A local checkpoint could sometimes be
    started before the previous LCP was restorable from a
    global checkpoint.
    (Bug#32519: http://bugs.mysql.com/32519)
  * MySQL Cluster: High numbers of API nodes on a slow or
    congested network could cause connection negotiation to
    time out prematurely, leading to the following issues:
       + Excessive retries
       + Excessive CPU usage
       + Partially connected API nodes
    (Bug#32359: http://bugs.mysql.com/32359)
  * MySQL Cluster: The failure of a master node could lead to
    subsequent failures in local checkpointing.
    (Bug#32160: http://bugs.mysql.com/32160)
  * MySQL Cluster: An error with an if statement in
    sql/ha_ndbcluster.cc could potentially lead to an
    infinite loop in case of failure when working with
    AUTO_INCREMENT columns in NDB tables.
    (Bug#31810: http://bugs.mysql.com/31810)
  * MySQL Cluster: The NDB storage engine code was not safe
    for strict-alias optimization in gcc 4.2.1.
    (Bug#31761: http://bugs.mysql.com/31761)
  * MySQL Cluster: It was possible in some cases for a node
    group to be "lost" due to missed local checkpoints
    following a system restart.
    (Bug#31525: http://bugs.mysql.com/31525)
  * MySQL Cluster: A query against a table with TEXT or BLOB
    columns that would return more than a certain amount of
    data failed with Got error 4350 'Transaction already
    aborted' from NDBCLUSTER.
    (Bug#31482: http://bugs.mysql.com/31482)
    This regression was introduced by
    Bug#29102: http://bugs.mysql.com/29102
  * MySQL Cluster: NDB tables having names containing
    non-alphanumeric characters (such as " $ ") were not
    discovered correctly.
    (Bug#31470: http://bugs.mysql.com/31470)
  * MySQL Cluster: A node failure during a local checkpoint
    could lead to a subsequent failure of the cluster during
    a system restart.
    (Bug#31257: http://bugs.mysql.com/31257)
  * MySQL Cluster: When handling BLOB columns, the addition
    of read locks to the lock queue was not handled
    correctly. (Bug#30764: http://bugs.mysql.com/30764)
  * MySQL Cluster: Discovery of NDB tables did not work
    correctly with INFORMATION_SCHEMA.
    (Bug#30667: http://bugs.mysql.com/30667)
  * MySQL Cluster: A filesystem close operation could fail
    during a node or system restart.
    (Bug#30646: http://bugs.mysql.com/30646)
  * MySQL Cluster: Transaction timeouts were not handled well
    in some circumstances, leading to excessive number of
    transactions being aborted unnecessarily.
    (Bug#30379: http://bugs.mysql.com/30379)
  * MySQL Cluster: The cluster management client could not
    connect, and would hang instead. This issue affected Mac
    OS X 64-bit only.
    (Bug#30366: http://bugs.mysql.com/30366)
  * MySQL Cluster: Attempting to restore a backup made on a
    cluster host using one endian to a machine using the
    other endian could cause the cluster to fail.
    (Bug#29674: http://bugs.mysql.com/29674)
  * MySQL Cluster: Log event requests to ndb_mgmd could time
    out, causing it to fail.
    (Bug#29621: http://bugs.mysql.com/29621)
  * MySQL Cluster: In some cases, the cluster managment
    server logged entries multiple times following a restart
    of mgmd. (Bug#29565: http://bugs.mysql.com/29565)
  * MySQL Cluster: ndb_mgm --help did not display any
    information about the -a option.
    (Bug#29509: http://bugs.mysql.com/29509)
  * MySQL Cluster: An interpreted program of sufficient size
    and complexity could cause all cluster data nodes to shut
    down due to buffer overruns.
    (Bug#29390: http://bugs.mysql.com/29390)
  * MySQL Cluster: ndb_size.pl failed on tables with FLOAT
    columns whose definitions included commas (for example,
    FLOAT(6,2)). (Bug#29228: http://bugs.mysql.com/29228)
  * MySQL Cluster: The error message for NDB error code 275
    (Out of transaction records for complete phase) was
    missing. (Bug#29139: http://bugs.mysql.com/29139)
  * MySQL Cluster: Reads on BLOB columns were not locked when
    they needed to be to guarantee consistency.
    (Bug#29102: http://bugs.mysql.com/29102)
    See also Bug#31482: http://bugs.mysql.com/31482
  * MySQL Cluster: A query using joins between several large
    tables and requiring unique index lookups failed to
    complete, eventually returning Uknown Error after a very
    long period of time. This occurred due to inadequate
    handling of instances where the Transaction Coordinator
    ran out of TransactionBufferMemory, when the cluster
    should have returned NDB error code 4012 (Request ndbd
    time-out). (Bug#28804: http://bugs.mysql.com/28804)
  * MySQL Cluster: There was a short interval during the
    startup process prior to the beginning of heartbeat
    detection such that, were an API or management node to
    reboot or a network failure to occur, data nodes could
    not detect this, with the result that there could be a
    lingering connection.
    (Bug#28445: http://bugs.mysql.com/28445)
  * MySQL Cluster: The description of the --print option
    provided in the output from ndb_restore --help was
    incorrect. (Bug#27683: http://bugs.mysql.com/27683)
  * MySQL Cluster: Restoring a backup made on a cluster host
    using one endian to a machine using the other endian
    failed for BLOB and DATETIME columns.
    (Bug#27543: http://bugs.mysql.com/27543,
    Bug#30024: http://bugs.mysql.com/30024)
  * MySQL Cluster: An invalid subselect on an NDB table could
    cause mysqld to crash.
    (Bug#27494: http://bugs.mysql.com/27494)
  * MySQL Cluster: An attempt to perform a SELECT ... FROM
    INFORMATION_SCHEMA.TABLES whose result included
    information about NDB tables for which the user had no
    privileges crashed the MySQL Server on which the query
    was performed. (Bug#26793: http://bugs.mysql.com/26793)
  * MySQL Cluster: Performing DELETE operations after a data
    node had been shut down could lead to inconsistent data
    following a restart of the node.
    (Bug#26450: http://bugs.mysql.com/26450)
  * MySQL Cluster: UPDATE IGNORE could sometimes fail on NDB
    tables due to the use of unitialized data when checking
    for duplicate keys to be ignored.
    (Bug#25817: http://bugs.mysql.com/25817)
  * MySQL Cluster: The cluster log was formatted
    inconsistently and contained extraneous newline
    characters. (Bug#25064: http://bugs.mysql.com/25064)
  * MySQL Cluster: A restart of the cluster failed when more
    than 1 REDO phase was in use.
    (Bug#22696: http://bugs.mysql.com/22696)
  * MySQL Cluster: When inserting a row into an NDB table
    with a duplicate value for a non-primary unique key, the
    error issued would reference the wrong key.
    This improves on an initial fix for this issue made in
    MySQL 5.1.13. (Bug#21072: http://bugs.mysql.com/21072)
  * MySQL Cluster: An insufficiently descriptive and
    potentially misleading Error 4006 (Connect failure - out
    of connection objects...) was produced when either of the
    following two conditions occurred:
      1. There were no more transaction records in the
         transaction coordinator
      2. an Ndb object in the NDB API was initialized with
         insufficient parallellism
    Separate error messages are now generated for each of
    these two cases. (Bug#11313: http://bugs.mysql.com/11313)
  * Partitioning: Replication: Replication of partitioned
    tables using the InnoDB storage engine failed with
    binlog-format=ROW or binlog-format=MIXED.
    (Bug#28430: http://bugs.mysql.com/28430)
  * Partitioning: It was possible to partition a table to
    which a foreign key referred.
    (Bug#32948: http://bugs.mysql.com/32948)
  * Partitioning: A query of the form SELECT col1 FROM table
    GROUP BY (SELECT col2 FROM table LIMIT 1); against a
    partitioned table having a SET column crashed the server.
    (Bug#32772: http://bugs.mysql.com/32772)
  * Partitioning: SHOW CREATE TABLE misreported the value of
    AUTO_INCREMENT for partitioned tables using either of the
    InnoDB or ARCHIVE storage engines.
    (Bug#32247: http://bugs.mysql.com/32247)
  * Partitioning: Selecting from
    INFORMATION_SCHEMA.PARTITIONS while partition management
    statements (for example, ALTER TABLE ... ADD PARTITION)
    were executing caused the server to crash.
    (Bug#32178: http://bugs.mysql.com/32178)
  * Partitioning: An error in the internal function
    mysql_unpack_partition() led to a fatal error in
    subsequent calls to open_table_from_share().
    (Bug#32158: http://bugs.mysql.com/32158)
  * Partitioning: Repeated updates of a table that was
    partitioned by KEY on a TIMESTAMP column eventually
    crashed the server.
    (Bug#32067: http://bugs.mysql.com/32067)
  * Partitioning: Changing the storage engine used by a table
    having subpartitions led to a server crash.
    (Bug#31893: http://bugs.mysql.com/31893)
  * Partitioning: ORDER BY ... DESC did not always work
    correctly when selecting from partitioned tables.
    (Bug#31890: http://bugs.mysql.com/31890)
    See also Bug#31001: http://bugs.mysql.com/31001
  * Partitioning: Selecting from a table partitioned by KEY
    on a VARCHAR column whose size was greater than 65530
    caused the server to crash.
    (Bug#31705: http://bugs.mysql.com/31705)
  * Partitioning: INSERT DELAYED into a partitioned table
    crashed the server.
    (Bug#31201: http://bugs.mysql.com/31201)
  * Partitioning: Using ALTER TABLE to partition an existing
    table having an AUTO_INCREMENT column could crash the
    server. (Bug#30878: http://bugs.mysql.com/30878)
    This regression was introduced by
    Bug#27405: http://bugs.mysql.com/27405
  * Partitioning: ALTER TABLE ... COALESCE PARTITION on a
    table partitioned by [LINEAR] HASH or [LINEAR] KEY caused
    the server to crash.
    (Bug#30822: http://bugs.mysql.com/30822)
  * Partitioning: LIKE queries on tables partitioned by KEY
    and using third-party storage engines could return
    incomplete results.
    (Bug#30480: http://bugs.mysql.com/30480)
    See also Bug#29320: http://bugs.mysql.com/29320,
    Bug#29493: http://bugs.mysql.com/29493,
    Bug#30563: http://bugs.mysql.com/30563
  * Partitioning: It was not possible to insert the greatest
    possible value for a given data type into a partitioned
    table. For example, consider a table defined as shown
    here:
       CREATE TABLE t (c BIGINT UNSIGNED)
        PARTITION BY RANGE(c) (
          PARTITION p0 VALUES LESS THAN MAXVALUE
        );
    The largest possible value for a BIGINT UNSIGNED column
    is 18446744073709551615, but the statement INSERT INTO t
    VALUES (18446744073709551615); would fail, even though
    the same statement succeeded were t not a partitioned
    table.
    In other words, MAXVALUE was treated as being equal to
    the greatest possible value, rather than as a least upper
    bound. (Bug#29258: http://bugs.mysql.com/29258)
  * Replication: When dropping a database containing a stored
    procedure while using row-cased replication, the delete
    of the stored procedure from the mysql.proc table was
    recorded in the binary log following the DROP DATABASE
    statement. To correct this issue, DROP DATABASE now uses
    statement-based replication.
    (Bug#32435: http://bugs.mysql.com/32435)
  * Replication: It was possible for the name of the relay
    log file to exceed the amount of memory reserved for it,
    possibly leading to a crash of the server.
    (Bug#31836: http://bugs.mysql.com/31836)
    See also Bug#28597: http://bugs.mysql.com/28597
  * Replication: Corruption of log events caused the server
    to crash on 64-bit Linux systems having 4 GB of memory or
    more. (Bug#31793: http://bugs.mysql.com/31793)
  * Replication: Trying to replicate an update of a row that
    was missing on the slave led to a failure on the slave.
    (Bug#31702: http://bugs.mysql.com/31702)
  * Replication: Table names were displayed as binary
    "garbage" characters in slave error messages. The issue
    was observed on 64-bit Windows but may have effected
    other platforms. (Bug#30854: http://bugs.mysql.com/30854)
  * Replication: One thread could read uninitialized memory
    from the stack of another thread. This issue was only
    known to occur in a mysqld process acting as both a
    master and a slave.
    (Bug#30752: http://bugs.mysql.com/30752)
  * Replication: It was possible to set
    SQL_SLAVE_SKIP_COUNTER such that the slave would jump
    into the middle of a transaction. This fix improves on
    one made for this bug in MySQL 5.1.20; the previous fix
    insured that the slave could not be made to jump into the
    middle of an event group, but the slave failed to
    recognize that BEGIN, COMMIT, and ROLLBACK statements
    could begin or end an event group.
    (Bug#28618: http://bugs.mysql.com/28618)
    See also Bug#12691: http://bugs.mysql.com/12691
  * Replication: Due a previous change in how the default
    name and location of the binlog file were determined,
    replication failed following some upgrades.
    (Bug#28597: http://bugs.mysql.com/28597)
    See also Bug#31836: http://bugs.mysql.com/31836
    This regression was introduced by
    Bug#20166: http://bugs.mysql.com/20166
  * Replication: Stored procedures having BIT parameters were
    not replicated correctly.
    (Bug#26199: http://bugs.mysql.com/26199)
  * Replication: Issuing SHOW SLAVE STATUS as mysqld was
    shutting down could cause a crash.
    (Bug#26000: http://bugs.mysql.com/26000)
  * Replication: If a temporary error occured inside an event
    group on an event that was not the first event of the
    group, the slave could get caught in an endless loop
    because the retry counter was reset whenever an event was
    executed successfully.
    (Bug#24860: http://bugs.mysql.com/24860)
    See also Bug#12691: http://bugs.mysql.com/12691,
    Bug#23171: http://bugs.mysql.com/23171
  * Replication: An UPDATE statement using a stored function
    that modified a non-transactional table was not logged if
    it failed. This caused the copy of the non-transactional
    table on the master have a row that the copy on the slave
    did not. (Bug#23333: http://bugs.mysql.com/23333)
    See also Bug#12713: http://bugs.mysql.com/12713
  * Replication: A replication slave sometimes failed to
    reconnect because it was unable to run SHOW SLAVE HOSTS.
    It was not necessary to run this statement on slaves
    (since the master should track connection IDs), and the
    execution of this statement by slaves was removed.
    (Bug#21132: http://bugs.mysql.com/21132)
    See also Bug#13963: http://bugs.mysql.com/13963,
    Bug#21869: http://bugs.mysql.com/21869
  * Replication: A replication slave sometimes stopped for
    changes that were idempotent (that is, such changes
    should have been considered "safe"), even though it
    should have simply noted that the change was already
    done, and continued operation.
    (Bug#19958: http://bugs.mysql.com/19958)
  * Cluster Replication: A replication slave could return
    "garbage" data that was not in recognizable row format
    due to a problem with the internal all_set() method.
    (Bug#33375: http://bugs.mysql.com/33375)
  * Cluster Replication: Memory was mistakenly freed for
    NdbBlob objects when adding an index while replicating
    the cluster, which could cause mysqld to crash.
    (Bug#33142: http://bugs.mysql.com/33142)
    See also Bug#18106: http://bugs.mysql.com/18106
  * Cluster Replication: Under certain conditions, the slave
    stopped processing relay logs. This resulted in the logs
    never being cleared and the slave eventually running out
    of disk space. (Bug#31958: http://bugs.mysql.com/31958)
  * Cluster Replication: A node failure during replication
    could lead to buckets out of order; now active
    subscribers are checked for, rather than empty buckets.
    (Bug#31701: http://bugs.mysql.com/31701)
  * Cluster Replication: When the master mysqld crashed or
    was restarted, no LOST_EVENTS entry was made in the
    binlog. (Bug#31484: http://bugs.mysql.com/31484)
    See also Bug#21494: http://bugs.mysql.com/21494
  * Cluster Replication: Incorrect handling of INSERT plus
    DELETE operations with regard to local checkpoints caused
    data node failures in multi-master replication setups.
    (Bug#30914: http://bugs.mysql.com/30914)
  * Cluster Replication: An issue with the
    mysql.ndb_apply_status table could cause NDB schema
    autodiscovery to fail in certain rare circumstances.
    (Bug#20872: http://bugs.mysql.com/20872)
  * Cluster API: A call to CHECK_TIMEDOUT_RET() in mgmapi.cpp
    should have been a call to DBUG_CHECK_TIMEDOUT_RET().
    (Bug#30681: http://bugs.mysql.com/30681)
  * Cluster API: An Ndb object in the NDB API was initialized
    with insufficient parallellism
  * API: When the language option was not set correctly, API
    programs calling mysql_server_init() crashed. This issue
    was observed only on Windows platforms.
    (Bug#31868: http://bugs.mysql.com/31868)
  * Corrected a typecast involving bool on Mac OS X 10.5
    (Leopard), which evaluated differently from earlier Mac
    OS X versions. (Bug#38217: http://bugs.mysql.com/38217)
  * Use of uninitialized memory for filesort in a subquery
    caused a server crash.
    (Bug#33675: http://bugs.mysql.com/33675)
  * CREATE TABLE ... SELECT created tables that for date
    columns used the obsolete Field_date type instead of
    Field_newdate. (Bug#33256: http://bugs.mysql.com/33256)
  * The fix for Bug#11230: http://bugs.mysql.com/11230 and
    Bug#26215: http://bugs.mysql.com/26215 introduced a
    significant input-parsing slowdown for the mysql client.
    This has been corrected.
    (Bug#33057: http://bugs.mysql.com/33057)
  * The correct data type for a NULL column resulting from a
    UNION could be determined incorrectly in some cases: 1)
    Not correctly inferred as NULL depending on the number of
    selects; 2) Not inferred correctly as NULL if one select
    used a subquery. (Bug#32848: http://bugs.mysql.com/32848)
  * For queries containing GROUP_CONCAT(DISTINCT col_list
    ORDER BY col_list), there was a limitation that the
    DISTINCT columns had to be the same as ORDER BY columns.
    Incorrect results could be returned if this was not true.
    (Bug#32798: http://bugs.mysql.com/32798)
  * SHOW EVENTS and selecting from the
    INFORMATION_SCHEMA.EVENTS table failed if the current
    database was INFORMATION_SCHEMA.
    (Bug#32775: http://bugs.mysql.com/32775)
  * Use of the cp932 character set with CAST() in an ORDER BY
    clause could cause a server crash.
    (Bug#32726: http://bugs.mysql.com/32726)
  * A subquery using an IS NULL check of a column defined as
    NOT NULL in a table used in the FROM clause of the outer
    query produced an invalid result.
    (Bug#32694: http://bugs.mysql.com/32694)
  * Specifying a non-existent column for an INSERT DELAYED
    statement caused a server crash rather than producing an
    error. (Bug#32676: http://bugs.mysql.com/32676)
  * Use of CLIENT_MULTI_QUERIES caused libmysqld to crash.
    (Bug#32624: http://bugs.mysql.com/32624)
  * The INTERVAL() function incorrectly handled NULL values
    in the value list.
    (Bug#32560: http://bugs.mysql.com/32560)
  * "GROUP BY expression WITH ROLLUP" could cause a server
    crash, if "expression" was the constant "NULL" or evaluated
    to NULL. (Bug#31095: http://bugs.mysql.com/31095,
    Bug#32558: http://bugs.mysql.com/32558)
  * ORDER BY UpdateXML(...) caused the server to crash in
    queries where UpdateXML() returned NULL.
    (Bug#32557: http://bugs.mysql.com/32557)
  * A SELECT ... GROUP BY bit_column query failed with an
    assertion if the length of the BIT column used for the
    GROUP BY was not an integer multiple of 8.
    (Bug#32556: http://bugs.mysql.com/32556)
  * Using SELECT INTO OUTFILE with 8-bit ENCLOSED BY
    characters led to corrupted data when the data was
    reloaded using LOAD DATA INFILE. This was because SELECT
    INTO OUTFILE failed to escape the 8-bit characters.
    (Bug#32533: http://bugs.mysql.com/32533)
  * For FLUSH TABLES WITH READ LOCK, the server failed to
    properly detect write-locked tables when running with
    low-priority updates, resulting in a crash or deadlock.
    (Bug#32528: http://bugs.mysql.com/32528)
  * The rules for valid column names were being applied
    differently for base tables and views.
    (Bug#32496: http://bugs.mysql.com/32496)
  * A query of the form SELECT @user_variable := constant AS
    alias FROM table GROUP BY alias WITH ROLLUP crashed the
    server. (Bug#32482: http://bugs.mysql.com/32482)
  * Sending several KILL QUERY statements to target a
    connection running SELECT SLEEP() could freeze the
    server. (Bug#32436: http://bugs.mysql.com/32436)
  * ssl-cipher values in option files were not being read by
    libmysqlclient. (Bug#32429: http://bugs.mysql.com/32429)
  * Repeated execution of a query containing a CASE
    expression and numerous AND and OR relations could crash
    the server. The root cause of the issue was determined to
    be that the internal SEL_ARG structure was not properly
    initialized when created.
    (Bug#32403: http://bugs.mysql.com/32403)
  * Referencing within a subquery an alias used in the SELECT
    list of the outer query was incorrectly permitted.
    (Bug#32400: http://bugs.mysql.com/32400)
  * If a global read lock acquired with FLUSH TABLES WITH
    READ LOCK was in effect, executing ALTER TABLE could
    cause a server crash.
    (Bug#32395: http://bugs.mysql.com/32395)
  * An ORDER BY query on a view created using a FEDERATED
    table as a base table caused the server to crash.
    (Bug#32374: http://bugs.mysql.com/32374)
  * Comparison of a BIGINT NOT NULL column with a constant
    arithmetic expression that evaluated to NULL mistakenly
    caused the error Column '...' cannot be null (error
    1048). (Bug#32335: http://bugs.mysql.com/32335)
  * Assigning a 65,536-byte string to a TEXT column (which
    can hold a maximum of 65,535 bytes) resulted in
    truncation without a warning. Now a truncation warning is
    generated. (Bug#32282: http://bugs.mysql.com/32282)
  * MIN() and MAX() could return incorrect results when an
    index was present if a loose index scan was used.
    (Bug#32268: http://bugs.mysql.com/32268)
  * Some uses of user variables in a query could result in a
    server crash. (Bug#32260: http://bugs.mysql.com/32260)
  * Memory corruption could occur due to large index map in
    Range checked for each record status reported by EXPLAIN
    SELECT. The problem was based in an incorrectly
    calculated length of the buffer used to store a
    hexadecimal representation of an index map, which could
    result in buffer overrun and stack corruption under some
    circumstances. (Bug#32241: http://bugs.mysql.com/32241)
  * Various test program cleanups were made: 1) mytest and
    libmysqltest were removed. 2) bug25714 displays an error
    message when invoked with incorrect arguments or the
    --help option. 3) mysql_client_test exits cleanly with a
    proper error status.
    (Bug#32221: http://bugs.mysql.com/32221)
  * The default grant tables on Windows contained information
    for host production.mysql.com, which should not be there.
    (Bug#32219: http://bugs.mysql.com/32219)
  * Under certain conditions, the presence of a GROUP BY
    clause could cause an ORDER BY clause to be ignored.
    (Bug#32202: http://bugs.mysql.com/32202)
  * For comparisons of the form date_col OP datetime_const
    (where OP is =, <, >, <=, or >=), the comparison is done
    using DATETIME values, per the fix for
    Bug#27590: http://bugs.mysql.com/27590. However that fix
    caused any index on date_col not to be used and
    compromised performance. Now the index is used again.
    (Bug#32198: http://bugs.mysql.com/32198)
  * DATETIME arguments specified in numeric form were treated
    by DATE_ADD() as DATE values.
    (Bug#32180: http://bugs.mysql.com/32180)
  * Killing a statement could lead to a race condition in the
    server. (Bug#32148: http://bugs.mysql.com/32148)
  * InnoDB does not support SPATIAL indexes, but could crash
    when asked to handle one. Now an error is returned.
    (Bug#32125: http://bugs.mysql.com/32125)


For parts 2 and 3 of the changes, please see the separate mails.


Enjoy !
Jörg

--
Joerg Bruehe, Senior Production Engineer
MySQL AB, www.mysql.com













--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to