MySQL 6.0.11-alpha


Izašao MySQL 6.0.11-alpha, ništa posebno, brdo fiksovanih bagova, i dalje teška alfa, i dalje daleko od produkcije. Ono što je značajno je da je ovo poslednji 6.0!! Od sad pa na dalje prelazimo na NOVI RELEASE MODEL.

O autoru

Bogdan Kecman

1 komentar

  • Functionality added or changed:

    * Incompatible Change: The optimizer_switch system variable
    controls optimizations that can be switched on and off. The
    syntax for flags in its value has changed from ‘no_opt_name’
    to ‘opt_name={on|off|default}’. For information about the new
    syntax, see Section 7.2.22, „Using optimizer_switch to Control
    the Optimizer.“

    * Replication: The global server variables sync_master_info and
    sync_relay_log_info are introduced for use on replication
    slaves to control synchronization of, respectively, the and files.
    In each case, setting the variable to a nonzero integer value
    N causes the slave to synchonize the corresponding file to
    disk after every N events. Setting its value to 0 allows the
    operation system to handle syncronization of the file instead.
    The actions of these variables, when enabled, are analogous to
    how the sync_binlog variable works with regard to binary logs
    on a replication master.
    These variables can also be set in my.cnf, or by using the
    server options –sync-master-info and –sync-relay-log-info
    An additional system variable relay_log_recovery is also now
    available. When enabled, this variable causes a replication
    slave to discard relay log files obtained from the replication
    master following a crash.
    This variable can also be set in my.cnf, or by using the
    –relay-log-recovery server option.
    This fix improves and expands upon one made in MySQL 6.0.10
    which introduced the sync_relay_log variable. For more
    information about all of the server system variables
    introduced by these fixes, see Section, „Replication
    Slave Options and Variables.“

    * now supports an –experimental=file_name
    option. It enables you to specify a file that contains a list
    of test cases that should be displayed with the [ exp-fail ]
    code rather than [ fail ] if they fail.

    * The MD5 algorithm now uses the Xfree implementation.

    * The RESTORE statement now has a SKIP_GAP_EVENT option that
    causes the restore operation not to write the gap event to the
    binary log that causes any replication slaves to stop
    replication. This is useful when RESTORE is run on a master
    server and the backup image does not contain databases that
    are replicated to the slaves.

    * Previously, the –secure-file-priv option and secure_file_priv
    system variable, if set to a directory, limited BACKUP
    DATABASE and RESTORE operations to files in the given
    directory. Now the –secure-backup-file-priv option and
    secure_backup_file_priv system variable apply instead.

    * The query cache now checks whether a SELECT statement begins
    with SQL_NO_CACHE to determine whether it can skip checking
    for the query result in the query cache. This is not supported
    when SQL_NO_CACHE occurs within a comment.

    * A new program, mysqlbackup, displays information from backups
    created with the BACKUP DATABASE statement.

    * MySQL now implements the SQL standard SIGNAL and RESIGNAL
    statements. See Section 12.8.8, „SIGNAL and RESIGNAL.“

    Bugs fixed:

    * Incompatible Change: For system variables that take values of
    ON or OFF, OF was accepted as a legal variable. Now system
    variables that take „enumeration“ values must be assigned the
    full value. This affects some other variables that previously
    could be assigned using unambiguous prefixes of allowable
    values, such as tx_isolation.

    * Incompatible Change: If a data definition language (DDL)
    statement occurred for a table that was being used by another
    session in an active transaction, statements could be written
    to the binary log in the wrong order. For example, this could
    happen if DROP TABLE occurred for a table being used in a
    transaction. This is now prevented by deferring release of
    metadata locks on tables used within a transaction until the
    transaction ends.
    This bug fix results in some incompatibilities with previous

    + A table that is being used by a transaction within one
    session cannot be used in DDL statements by other
    sessions until the transaction ends.

    + FLUSH TABLES WITH READ LOCK blocks for active
    transactions that hold metadata locks until those
    transactions end. The same is true for attempts to set
    the global value of the read_only system variable.

    * Important Change: Replication: CHANGE MASTER TO …
    MASTER_HOST=“ — explicitly setting MASTER_HOST equal to an
    empty string — created a file with an empty host
    field. This led to a The server is not configured as slave
    error when attempting to execute a START SLAVE statement. Now,
    if MASTER_HOST is set to an empty string, the CHANGE MASTER TO
    statement fails with an error.

    * Replication: Important Note: Binary logging with
    –binlog_format=ROW failed when a change to be logged included
    more than 251 columns. This issue was not known to occur with
    mixed-format or statement-based logging.
    See also Bug#42914:

    * Replication: The SHOW SLAVE STATUS connection thread competed
    with the slave SQL thread for use of the error message buffer.
    As a result, the connection thread sometimes received
    incomplete messages. This issue was uncovered with valgrind
    when message strings were passed without NULL terminators,
    causing the error Conditional jump or move depends on
    uninitialised value(s).

    * Replication: This fix handles 2 issues encountered on
    replication slaves during startup:

    1. A failure while allocating the master info structure
    caused the slave to crash.

    2. A failure during recovery caused the relay log file not
    to be properly initialized which led to a crash on the

    * Replication: Assigning an invalid directory for the
    –slave-load-tmpdir caused the replication slave to crash.

    * Replication: The mysql.procs_priv system table was not
    replicated. (Bug#42217:

    * Replication: When –binlog_format was set to STATEMENT, a
    statement unsafe for statement-based logging caused an error
    or warning to be issued even if sql_log_bin was set to 0.

    * Replication: An INSERT DELAYED into a TIMESTAMP column issued
    concurrently with a an insert on the same column not using
    DELAYED, but applied after the other insert, was logged using
    the same timestamp as generated by the other (non-DELAYED)
    insert. (Bug#41719:

    * Replication: When using MIXED replication format and temporary
    tables were created in statement-based mode, but a later
    operation in the same session caused a switch to row-based
    mode, the temporary tables were not dropped on the slave at
    the end of the session.
    See also Bug#43046:
    This regression was introduced by

    * Replication: When using the MIXED replication format, UPDATE
    and DELETE statements that searched for rows where part of the
    key had nullable BIT columns failed. This occurred because
    operations that inserted the data were replicated as
    statements, but UPDATE and DELETE statements affecting the
    same data were replicated using row-based format.
    This issue did not occur when using statement-based
    replication (only) or row-based replication (only).
    See also Bug#39648:

    * Replication: The MIXED binary logging format did not switch to
    row-based mode for statements containing the LOAD_FILE()
    function. (Bug#39701:

    * Replication: The server SQL mode in effect when a stored
    procedure was created was not retained in the binary log. This
    could cause a CREATE PROCEDURE statement that succeeded on the
    master to fail on the slave.
    This issue was first noticed when a stored procedure was
    created when ANSI_QUOTES was in effect on the master, but
    could possibly cause failed CREATE PROCEDURE statements and
    other problems on the slave when using other server SQL modes
    as well. (Bug#39526:

    * Replication: If –secure-file-priv was set on the slave, it
    was unable to execute LOAD DATA INFILE statements sent from
    the master when using mixed-format or statement-based
    As a result of this fix, this security restriction is now
    ignored on the slave in such cases; instead the slave checks
    whether the files were created and should be read by the slave
    in its –slave-load-tmpdir.

    * Replication: Server IDs greater than 2147483647 (232 – 1)
    were represented by negative numbers in the binary log.

    * Replication: The value of Slave_IO_running in the output of
    SHOW SLAVE STATUS did not distinguish between all 3 possible
    states of the slave I/O thread (not running; running but not
    connected; connected). Now the value Connecting (rather than
    No) is shown when the slave I/O thread is running but the
    slave is not connected to a replication master.
    The server system variable Slave_running also reflects this
    change, and is now consistent with what is shown for
    Slave_IO_running. (Bug#30703:,

    * Replication: Queries which were written to the slow query log
    on the master were not written to the slow query log on the
    slave. (Bug#23300:

    * Replication: When the server SQL mode included IGNORE_SPACE,
    statement-based replication of LOAD DATA INFILE … INTO
    tbl_name failed because the statement was read incorrectly
    from the binary log; a trailing space was omitted, causing the
    statement to fail with a syntax error when run on the slave.
    See also Bug#43746:

    * Replication: When its disk becomes full, a replication slave
    may wait while writing the binary log, relay log or MyISAM
    tables, continuing after space has been made available. The
    error message provided in such cases was not clear about the
    frequency with which checking for free space is done (once
    every 60 seconds), and how long the server waits after space
    has been freed before continuing (also 60 seconds); this
    caused users to think that the server had hung.
    These issues have been addressed by making the error message
    clearer, and dividing it into two separate messages:

    1. The error message Disk is full writing ‘filename’
    (Errcode: error_code). Waiting for someone to free
    space… (Expect up to 60 secs delay for server to
    continue after freeing disk space) is printed only once.

    2. The warning Retry in 60 secs, Message reprinted in 600
    secs is printed once every for every 10 times that the
    check for free space is made; that is, the check is
    performed once each 60 seconds, but the reminder that
    space needs to be freed is printed only once every 10
    minutes (600 seconds).

    * Memory corruption of join buffers could occur when using the
    Batched Key Access algorithm with incremental join buffers to
    execute join operations for a query over several tables that
    selects BLOB values. (Bug#44250:

    * The server could crash at startup when initializing plugins
    listed in the plugin table.

    * A RESTORE operation that restored a MyISAM table using the
    native MyISAM restore driver could cause the MyISAM key cache
    to be disabled. (Bug#44068:

    * In some cases, when the Batched Key Access algorithm is used
    with join_cache_level equal to 6, multi-join queries could
    return incorrect results.

    * valgrind would report errors for the StorageInterface,
    StorageHAndler and CmdGen portions of Falcon.

    * On 64-bit debug builds, code in safemalloc resulted in errors
    due to use of a 32-bit value for 64-bit allocations.

    * When performing a high number of concurrent index updates on a
    Falcon table, mysqld could crash due to an assertion.

    * An attempt by a user who did not have the SUPER privilege to
    kill a system thread could cause a server crash.

    * On Windows, incorrectly specified link dependencies in
    CMakeLists.txt resulted in link errors for mysql_embedded,
    mysqltest_embedded, and mysql_client_test_embedded.

    * make distcheck failed to properly handle subdirectories of
    storage/ndb. (Bug#43614:

    * Incorrect use of parser information could lead to acquisition
    of incorrect lock types.

    * Upgrading MySQL to 6.0.10 from 6.0.9 when using Falcon tables
    and the mysql_upgrade tool would cause mysqld to crash during
    start up. (Bug#43562:

    * Running a SELECT using a range query on FLOAT on a Maria table
    could return invalid result sets.

    * Running a SELECT using a range query on with <> or < with a negative values on a Maria table could return invalid result sets. (Bug#43530:

    * Running a SELECT on a multi-range query with a LIMIT clause on
    a Maria table could return invalid result sets.

    * Executing a LIMIT … FOR UPDATE statement on a Falcon table
    when using transactions with concurrent threads could cause a
    crash because the record information cannot be accessed
    correctly. (Bug#43488:

    * When performing SELECT statements on a Falcon table using an
    indexed INTEGER column could return incorrect row matches.

    * RESTORE on a case-insensitive server failed if the backup
    image contained databases or tables with uppercase names. Now,
    RESTORE handles this case by converting the names to lowercase
    in the restore catalog, as long as there are no duplicate
    names after the conversion.

    * Use of USE INDEX hints could cause EXPLAIN EXTENDED to crash.

    * BACKUP DATABASE stored incorrect table counts in the backup
    image. (Bug#43324:

    * Assigning a value to the backupdir system variable resulted in
    Valgrind errors. (Bug#43303:

    * mysql crashed if a request for the current database name
    returned an empty result, such as after the client has
    executed a preceding SET sql_select_limit=0 statement.

    * If the value of the version_comment system variable was too
    long, the mysql client displayed a truncated startup message.

    * Compilation failures on Windows Vista using Visual Studio 2008
    Professional were corrected.

    * Recovering a Falcon table from a failure when the table
    contains BLOB columns could cause an assertion failure.

    * On 32-bit Windows, mysqld could not use large buffers due to a
    2GB user mode address limit.

    * mysqld would crash when using Falcon tables during shutdown if
    the server was running in embedded mode.

    * The MySQL Backup library had incorrect logic and error
    reporting for metadata saving.

    * Queries of the following form returned an empty result:
    SELECT … WHERE … (col=col AND col=col) OR …
    (false expression)

    * A two-way join query with a GROUP BY or ORDER BY clause could
    produce incorrect results when rows of the first table are
    accessed by an index compatible with the GROUP BY or ORDER BY
    list while the second table is joined using the Batched Key
    Access algorithm. (Bug#42955:

    * The strings/CHARSET_INFO.txt file was not included in source
    distributions. (Bug#42937:

    * When running REPAIR on a crashed Falcon table can crash mysqld
    if pages have been incorrectly marked dirty, but not locked,
    during write. (Bug#42824:

    * stderr should be unbuffered, but when the server redirected
    stderr to a file, it became buffered.

    * The DATA_TYPE column of the INFORMATION_SCHEMA.COLUMNS table
    displayed the UNSIGNED attribute for floating-point data
    types. (The column should contain only the data type name.)

    * Recovery of Falcon tables while there were active transaction
    during the crash may fail to recover completely.

    * Use of semijoin optimization could cause a server crash.

    * When Falcon is populating the INFORMATION_SCHEMA.TABLESPACES
    table, an exception can be raised because required result set
    has been closed before the resultset has been completed. This
    can happen during a BACKUP operation.

    * Assigning a value to the backupdir system variable resulted in
    a memory leak. (Bug#42695:

    * Assigning an incorrect value to the backup_progress_log_file
    system variable resulted in Valgrind errors.

    * When performing SELECT queries on tables containing TIMESTAMP
    or DATETIME colums with indexes using a WHERE clause comparing
    the field value to NULL using the <= or <> operators, the
    wrong information would be returned.

    * A dangling pointer in mysys/my_error.c could lead to client
    crashes. (Bug#42675:

    * mysqldump included views that were excluded with the
    –ignore-table option.

    * An earlier bug fix resulted in the problem that the InnoDB
    plugin could not be used with a server that was compiled with
    the built-in InnoDB. To handle this two changes were made:

    + The server now supports an –ignore-builtin-innodb
    .html#option_mysqld_ignore-builtin-innodb) option that
    causes the server to behave as if the built-in InnoDB is
    not present. This option causes other InnoDB options not
    to be recognized.

    + For the INSTALL PLUGIN statement, the server reads option
    (my.cnf) files just as during server startup. This
    enables the plugin to pick up any relevant options from
    those files. Consequently, a plugin no longer is started
    with each option set to its default value.
    Because of this change, it is possible to add plugin
    options to an option file even before loading a plugin
    (if the loose prefix is used). It is also possible to
    uninstall a plugin, edit my.cnf, and install the plugin
    again. Restarting the plugin this way enables it to the
    new option values without a server restart.

    InnoDB Plugin versions 1.0.4 and higher will take advantage of
    this bug fix. Although the InnoDB Plugin is source code
    compatible with multiple MySQL releases, a given binary InnoDB
    Plugin can be used only with a specific MySQL release. When
    InnoDB Plugin 1.0.4 is released, it is expected to be compiled
    for MySQL 5.1.34. For 5.1.33, you can use InnoDB Plugin 1.0.3,
    but you must build from source.
    This regression was introduced by

    * With the ONLY_FULL_GROUP_BY SQL mode enabled, some legal
    queries failed. (Bug#42567:

    * Recovery of a Falcon table with a large number of rows can
    cause a failure in the page type written for the internal

    * Passing an unknown time zone specification to CONVERT_TZ()
    resulted in a memory leak.

    * Tables could enter open table cache for a thread without being
    properly cleaned up, leading to a server crash.

    * Previously, RESTORE would crash if the backup image contained
    tables originally stored in a tablespace that no longer
    existed at RESTORE time. Now the tablespace is recreated like
    it was at BACKUP DATABASE time if it does not exist when
    RESTORE is executed. (Bug#42402:

    * If the server was started with
    –thread_handling=pool-of-threads, the MAX_QUERIES_PER_HOUR
    user resource limit. (Bug#42384:

    * Recovery of Falcon tables with indexes can fail because the
    index page information has not been recorded properly.

    * Using a LIKE clause on a Maria table using an index and the
    CP1251 collation would return invalid data.

    * Running a SELECT using a JOIN on a Maria table could return
    invalid result sets. (Bug#42298:

    * Running multi-range queries on Maria tables could cause a
    crash. (Bug#42297:

    * Using a falcon-scavenge-schedule of * * * * * would cause
    Falcon to never execute the required threads to operate.

    * If the server was started with an option that had a missing or
    invalid value, a subsequent error that would cause normally
    the server to shut down could cause it to crash instead.

    * Using ORDER BY and or LIMIT on Falcon tables could give
    inconsistent results for rows that contain NULL columns in the
    corresponding ORDER BY clause.

    * For InnoDB tables, there was a race condition for ALTER TABLE,
    periodically checking whether table copying can be committed.

    * In InnoDB recovery after a server crash, table lookup could
    fail and corrupt the data dictionary cache.

    * mysqldumpslow parsed the –debug and –verbose options
    incorrectly. (Bug#42027:

    * BACKUP DATABASE and RESTORE did not implement backup and
    restore of privileges for stored procedures and stored
    functions. (Bug#41979:

    * Recovering a Falcon table that uses BLOB columns could cause
    unbounded tablespace growth before recovery completes.

    * Recovery of Falcon tables could fail with an indicating that a
    wrong page type was identified in the Falcon serial log.

    * RESTORE crashed for Falcon tables.

    * With more than two arguments, LEAST(), GREATEST(), and CASE
    could unnecessarily return Illegal mix of collations errors.

    * Queries that used the loose index scan access method could
    return no rows. (Bug#41610:

    * RESTORE failed if it tried to restore a privilege for a
    non-existent object. (Bug#41578:

    * In InnoDB recovery after a server crash, rollback of a
    transaction that updated a column from NULL to NULL could
    cause another crash. (Bug#41571:

    * The mysql client could misinterpret its input if a line was
    longer than an internal buffer.

    * The error message for a too-long column comment was Unknown
    error rather than a more appropriate message.

    * The Falcon CycleManager has been updated, which addresses a
    number of issues when examining records in various transaction
    states and their visisbility/isolation in relation to other
    threads. (Bug#41391:,

    * Use of SELECT * allowed users with rights to only some columns
    of a view to access all columns.

    * If the tables underlying a MERGE table had a primary key but
    the MERGE table itself did not, inserting a duplicate row into
    the MERGE table caused a server crash.

    * In the help command output displayed by mysql, the description
    for the \c (clear) command was misleading.

    * Several resource leaks were corrected in the error-handling
    code for the MySQL Backup library.

    * The server did not robustly handle problems hang if a table
    opened with HANDLER needed to be re-opened because it had been
    altered to use a different storage engine that does not
    support HANDLER. The server also failed to set an error if the
    re-open attempt failed. These problems could cause the server
    to crash or hang. (Bug#41110:,

    * SELECT statements executed concurrently with INSERT statements
    for a MyISAM table could cause incorrect results to be
    returned from the query cache.

    * For prepared statements, multibyte character sets were not
    taking into account when calculating max_length for string
    values and mysql_stmt_fetch() could return truncated strings.

    * For user-defined variables in a query result, incorrect length
    values were returned in the result metadata.

    * Using RESTORE to restore a database through a named pipe
    resulted in corrupt data.

    * Performing SELECT operations on Falcon tables using the
    maximum BIG INT value would fail to return matching rows.

    * For some queries, an equality propagation problem could cause
    a = b and b = a to be handled differently.

    * With strict SQL mode enabled, setting a system variable to an
    out-of-bounds value caused an assertion failure.

    * Table temporary scans were slower than necessary due to use of
    mmap rather than caching, even with the myisam_use_mmap system
    variable disabled. (Bug#40634:

    * Indexes on Falcon tables using numeric columns could return
    incorrect information.

    * The load_defaults(), my_search_option_files() and
    my_print_default_files() functions in the C client library
    were subject to a race condition in multi-threaded operation.

    * For a view that references a table in another database,
    mysqldump wrote the view name qualified with the current
    database name. This makes it impossible to reload the dump
    file into a different database.

    * On platforms where long and pointer variables have different
    sizes, MyISAM could copy key statistics incorrectly, resulting
    in a server crash or incorrect cardinality values.

    * Falcon could cause an assertion when the system has run out of
    memory and tries to report the memory allocation failure.

    * DELETE tried to acquire write (not read) locks for tables
    accessed within a subquery of the WHERE clause.

    * mysql_upgrade did not remove the online_backup and
    online_backup_progress tables from the mysql database. (These
    are what the backup_history and backup_progress tables were
    called previously.) (Bug#39655:

    * With row-based binary logging, replication of InnoDB tables
    containing NULL-valued BIT columns could fail.

    * When using Falcon and the system runs out of all memory and
    swap space, mysqld could hang while attempting to write an
    error message. (Bug#39552:

    * The mysql_stmt_close() C API function did not flush all
    pending data associated with the prepared statement.

    * Updating Falcon tables after an online ALTER ADD COLUMN
    operation could fail. (Bug#39445:

    * Following ALTER TABLE … DISCARD TABLESPACE for an InnoDB
    table, an attempt to determine the free space for the table
    before the ALTER TABLE operation had completely finished could
    cause a server crash. (Bug#39438:

    * perror did not produce correct output for error codes 153 to
    163. (Bug#39370:

    * If –basedir was specified, mysqld_safe did not use it when
    attempting to locate my_print_defaults.

    * Several functions in libmysqld called exit() when an error
    occurred rather than returning an error to the caller.

    * Performing an online ALTER TABLE statement against a Falcon
    table, the Falcon serial log could grow beyond the maximum
    permitted size for a serial log, ignoring both the rotation
    and truncation. (Bug#39130:

    * Previously, the num_objects column in the backup_history table
    showed only the number of tables in the backup image. It now
    shows the number of objects with names (tablespaces,
    databases, tables, views, stored programs).

    * BACKUP DATABASE treated the database list in case-sensitive
    fashion, even on case-insensitive file systems.

    * The ALTER ROUTINE privilege incorrectly allowed SHOW CREATE
    TABLE. (Bug#38347:

    * BACKUP DATABASE crashed if there was no default database.

    * Setting a savepoint with the same name as an existing
    savepoint incorrectly deleted any other savepoints that had
    been set in the meantime. For example, setting savepoints
    named a, b, c, b resulted in savepoints a, b, rather than the
    correct savepoints a, c, b.

    * Locking of myisam.log did not work correctly on Windows.

    * –help output for myisamchk did not list the –HELP option.

    * Setting the session value of the debug system variable also
    set the global value. (Bug#38054:

    * Comparisons between row constructors, such as (a, b) = (c, d)
    resulted in unnecessary Illegal mix of collations errors for
    string columns. (Bug#37601:

    * A workload consisting of CREATE TABLE … SELECT and DML
    operations could cause deadlock.

    * If a user created a view that referenced tables for which the
    user had disjoint privileges, an assertion failure occurred.

    * Trying to recover Falcon tables after a crash when the
    corresponding tables and tablespaces have not been created
    before the crash could cause a recovery failure.

    * When MySQL was configured with the –with-max-indexes=128
    option, mysqld crashed.

    * The event, general_log, and slow_log tables in the mysql
    database store server_id values, but did not use an UNSIGNED
    column and thus were not able to store the full range of ID
    values. (Bug#36540:

    * Setting the join_buffer_size variable to its minimum value
    produced spurious warnings.

    * The audit plugin was not receiving MYSQL_AUDIT_GENERAL_ERROR
    events. (Bug#36098:

    * The use of NAME_CONST() can result in a problem for CREATE
    TABLE … SELECT statements when the source column expressions
    refer to local variables. Converting these references to
    NAME_CONST() expressions can result in column names that are
    different on the master and slave servers, or names that are
    too long to be legal column identifiers. A workaround is to
    supply aliases for columns that refer to local variables.
    Now a warning is issued in such cases that indicate possible
    problems. (Bug#35383:

    * SHOW CREATE EVENT output did not include the DEFINER clause.

    * mysqld would crash in a concurrent workload with INSERT/CREATE
    TABLE/DROP TABLE or INSERT/ALTER TABLE combinations on Falcon
    tables. (Bug#35255:

    * It was not possible to interrupt a long running BACKUP
    DATABASE or RESTORE operation.

    * Several deprecated or obsolete settings were removed from the
    sample option files. (Bug#34521:

    * Searching for 0x00 in Falcon tables using the VARBINARY column
    type would fail to return the correct rows. In addition, a
    crash could be encountered when modifying a column to the
    VARBINARY type. (Bug#34478:,

    * A subquery using SELECT … FOR UPDATE on a Falcon table fails
    to lock table correctly during the UPDATE.

    * With Falcon tables running concurrent transactions, some
    transactions may not be rolled back correctly, leading to an
    infinite loop. (Bug#34174:

    * INSTALL PLUGIN and UNINSTALL PLUGIN did not handle plugin
    identifiers consistently with respect to lettercase.

    * RESTORE often would not correctly identify the tablespace into
    which a Falcon table should be restored.

    * mysqldump –compatible=mysql40 emitted statements referring to
    the character_set_client system variable, which is unknown
    before MySQL 4.1. Now the statements are enclosed in
    version-specific comments.

    * If Falcon runs out of memory while inserting records and you
    try to alter the affected table, you may get a record memory
    is exhausted error, and the table can no longer be used or
    accessed. (Bug#33177:

    * The DDL blocker for BACKUP DATABASE and RESTORE did not block
    all statements that it should. The blocker is now called the
    Backup Metadata Lock and blocks statements that change
    database metadata. (Bug#32702:

    * Detection by configure of several functions such as
    setsockopt(), bind(), sched_yield(), and gtty() could fail.

    * Use of MBR spatial functions such as MBRTouches() with columns
    of InnoDB tables caused a server crash rather than an error.

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

    * The mysql client mishandled input parsing if a delimiter
    command was not first on the line.

    * SHOW PRIVILEGES listed the CREATE ROUTINE privilege as having
    a context of Functions,Procedures, but it is a database-level
    privilege. (Bug#30305:

    erroneously reported a table to be corrupt if the table did
    not exist or the statement was terminated with KILL.

    * For InnoDB tables that have their own .ibd tablespace file, a
    superfluous ibuf cursor restoration fails! message could be
    written to the error log. This warning has been suppressed.

    * Internal base64_xxx() functions were renamed to have a prefix
    of my_ to avoid conflicts with other libraries.

    * The Time column for SHOW PROCESSLIST output and the value of
    now can have negative values. Previously, the column was
    unsigned and negative values were displayed incorrectly as
    large positive values. Negative values can occur if a thread
    alters the time into the future with SET TIMESTAMP = value or
    the thread is executing on a slave and processing events from
    a master that has its clock set ahead of the slave.

    * Restoring a mysqldump dump file containing FEDERATED tables
    failed because the file contained the data for the table. Now
    only the table definition is dumped (because the data is
    located elsewhere). (Bug#21360:

    * SHOW CREATE DATABASE did not account for the value of the
    lower_case_table_names system variable.

    * Incorrect length metadata could be returned for LONG TEXT
    columns when a multibyte server character set was used.

    * ROUND() sometimes returned different results on different
    platforms. (Bug#15936:

Ključne Reči