Author: paul
Date: 2008-12-01 18:14:10 +0100 (Mon, 01 Dec 2008)
New Revision: 12714
Log:
r36274@frost: paul | 2008-12-01 10:35:57 -0500
Document bugfixes:
Bug#26704: Failing DROP DATABASE brings mysql-client out of sync
Bug#40282: --log-backup-output w/o argument sets logging to wrong value
Modified:
trunk/dynamic-docs/changelog/mysqld-1.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:39854
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:36273
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:34596
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:39854
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:36274
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:34596
Modified: trunk/dynamic-docs/changelog/mysqld-1.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-1.xml 2008-12-01 17:13:59 UTC (rev 12713)
+++ trunk/dynamic-docs/changelog/mysqld-1.xml 2008-12-01 17:14:10 UTC (rev 12714)
Changed blocks: 1, Lines Added: 34921, Lines Deleted: 0; 738555 bytes
@@ -34927,4 +34927,34925 @@
</logentry>
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="indexes"/>
+ <manual type="ORDER BY"/>
+ <manual type="ASC"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40954"/>
+ <introducedby bugid="30573"/>
+ <introducedby bugid="33257"/>
+ <introducedby bugid="33555"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.30-ndb-6.3.20"/>
+ <version ver="5.1.30-ndb-6.4.0"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A query on a user-partitioned table caused MySQL to crash, where
+ the query had the following characteristics:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The query's <literal>WHERE</literal> clause referenced
+ an indexed column that was also in the partitioning key.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The query's <literal>WHERE</literal> clause included a
+ value found in the partition.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The query's <literal>WHERE</literal> clause used the
+ <literal><</literal> or <literal><></literal>
+ operators to compare with the indexed column's value
+ with a constant.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The query used an <literal>ORDER BY</literal> clause, and
+ the same indexed column was used in the <literal>ORDER
+ BY</literal> clause.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>ORDER BY</literal> clause used an explcit or
+ implicit <literal>ASC</literal> sort priority.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ Two examples of such a query are given here, where
+ <literal>a</literal> represents an indexed column used in the
+ table's partitioning key:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+<programlisting>
+SELECT * FROM <replaceable>table</replaceable> WHERE a < <replaceable>constant</replaceable> ORDER BY a;
+</programlisting>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+<programlisting>
+SELECT * FROM <replaceable>table</replaceable> WHERE a <> <replaceable>constant</replaceable> ORDER BY a;
+</programlisting>
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ </message>
+
+ <message ver="5.1.30-ndb-6.2.17">
+
+ <para>
+ This bug was introduced in MySQL Cluster NDB 6.2.16.
+ </para>
+
+ </message>
+
+ <message ver="5.1.30-ndb-6.3.20">
+
+ <para>
+ This bug was introduced in MySQL Cluster NDB 6.3.19.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="bind-address"/>
+ <manual type="ndb_mgm_listen_event()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38473"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The MGM API function <literal>ndb_mgm_listen_event()</literal>
+ ignored bind addresses.
+ </para>
+
+ <para>
+ As part of this fix, it is now possible to specify bind
+ addresses in connectstrings. See
+ <xref linkend="mysql-cluster-connectstring"/>, for more
+ information.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="diskdata"/>
+ <manual type="CREATE TABLESPACE"/>
+ <manual type="ALTER TABLESPACE"/>
+ <manual type="CREATE LOGFILE GROUP"/>
+ <manual type="ALTER LOGFILE GROUP"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40921"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Issuing concurrent <literal>CREATE TABLESPACE</literal>,
+ <literal>ALTER TABLESPACE</literal>, <literal>CREATE LOGFILE
+ GROUP</literal>, or <literal>ALTER LOGFILE GROUP</literal>
+ statements on separate SQL nodes caused a resource leak that led
+ to data node crashes when these statements were used again
+ later.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="strings"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38662"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Memory leaks could occur in handling of strings used for storing
+ cluster metadata and providing output to users.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40847"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When performing an initial start of a data node, fragment log
+ files were always created sparsely — that is, not all
+ bytes were written. Now it is possible to override this behavior
+ using the new <literal>InitFragmentLogFiles</literal>
+ configuration parameter.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="mgmapi"/>
+ <manual type="errors"/>
+ <highlight type="importantchange"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40498"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ MGM API applications exited without raising any errors if the
+ connection to the management server was lost. The fix for this
+ issue includes two changes:
+ <orderedlist>
+
+ <listitem>
+ <para>
+ The MGM API now provides its own
+ <literal>SIGPIPE</literal> handler to catch the
+ <quote>broken pipe</quote> error that occurs when writing
+ to a closed or reset socket. This means that MGM API now
+ behaves the same as NDB API in this regard.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A new function
+ <literal>ndb_mgm_set_ignore_sigpipe()</literal> has been
+ added to the MGM API. This function makes it possible to
+ bypass the <literal>SIGPIPE</literal> handler provded by
+ the MGM API.
+ </para>
+ </listitem>
+
+ </orderedlist>
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="NoOfReplicas"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="18621"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.4.0"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A data node failure when <literal>NoOfReplicas</literal> was
+ greater than 2 caused all cluster SQL nodes to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="log files"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40815"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Undo logs and data files were created in 32K increments. Now
+ these files are created in 512K increments, resulting in shorter
+ creation times.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <highlight type="importantnote"/>
+ <manual type="--binlog-format"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40586"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ This release of MySQL Cluster derives in part from MySQL 5.1.29,
+ where the default value for the <option>--binlog-format</option>
+ option changed to <literal>STATEMENT</literal>. That change does
+ <emphasis>not</emphasis> affect this or future MySQL Cluster NDB
+ 6.x releases, where the default value for this option remains
+ <literal>MIXED</literal>, since MySQL Cluster Replication does
+ not work with the statement-based format.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39180"/>
+ <seealsobug bugid="38609"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A segfault in <literal>Logger::Log</literal> caused
+ <command>ndbd</command> to hang indefinitely. This fix improves
+ on an earlier one for this issue, first made in MySQL Cluster
+ NDB 6.2.16 and MySQL Cluster NDB 6.3.17.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="redo logs"/>
+ <manual type="starting"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40734"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Redo log creation was very slow on some platforms, causing MySQL
+ Cluster to start more slowly than necessary with some
+ combinations of hardware and operating system. This was due to
+ all write operations being synchronized to disk while creating a
+ redo log file. Now this synchronization occurs only after the
+ redo log has been created.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="TC takeover"/>
+ <manual type="API node"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40697"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Transaction failures took longer to handle than was necessary.
+ </para>
+
+ <para>
+ When a data node acting as transaction coordinator (TC) failed,
+ the surviving data nodes did not inform the API node initiating
+ the transaction of this until the failure had been processed by
+ all protocols. However, the API node needed only to know about
+ failure handling by the transaction protocol — that is, it
+ needed to be informed only about the TC takeover process. Now,
+ API nodes (including MySQL servers acting as cluster SQL nodes)
+ are informed as soon as the TC takeover is complete, so that it
+ can carry on operating more quickly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="NdbBlob"/>
+ <manual type="NdbScanOperation"/>
+ <manual type="NdbOperation"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40242"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It was not always possible to access parent objects directly
+ from <literal>NdbBlob</literal>,
+ <literal>NdbOperation</literal>, and
+ <literal>NdbScanOperation</literal> objects. To alleviate this
+ problem, a new <literal>getNdbOperation()</literal> method has
+ been added to <literal>NdbBlob</literal> and new
+ getNdbTransaction() methods have been added to
+ <literal>NdbOperation</literal> and
+ <literal>NdbScanOperation</literal>. In addition, a const
+ variant of <literal>NdbOperation::getErrorLine()</literal> is
+ now also available.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="NdbScanOperation::getBlobHandle()"/>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40241"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>NdbScanOperation::getBlobHandle()</literal> failed when
+ used with incorrect column names or numbers.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="diskdata"/>
+ <manual type="variable-length columns"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39645"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Disk-based variable-length columns were not always handled like
+ their memory-based equivalents, which could potentially lead to
+ a crash of cluster data nodes.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <highlight type="clusterapi"/>
+ <manual type="errors"/>
+ <manual type="BLOB"/>
+ <manual type="TEXT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39867"/>
+ <fixes bugid="39879"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Failed operations on <literal role="type">BLOB</literal> and
+ <literal role="type">TEXT</literal> columns were not always
+ reported correctly to the originating SQL node. Such errors were
+ sometimes reported as being due to timeouts, when the actual
+ problem was a transporter overload due to insufficient buffer
+ space.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_mgm"/>
+ <manual type="CLUSTERLOG STATISTICS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39839"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Events logged after setting <literal>ALL CLUSTERLOG
+ STATISTICS=15</literal> in the management client did not always
+ include the node ID of the reporting node.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="RBR"/>
+ <manual type="UPDATE"/>
+ <manual type="DELETE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38230"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ </versions>
+
+ <message>
+
+ <para>
+ With row-based replication, <literal>UPDATE</literal> and
+ <literal>DELETE</literal> statements using
+ <literal>LIMIT</literal> and a table's primary key could
+ produce different results on the master and slave.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="SHOW CREATE TABLE"/>
+ <manual type="usability"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="14362"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When <literal>SHOW CREATE TABLE</literal> was used on a
+ partitioned table, all of the table's
+ <literal>PARTITION</literal> and <literal>SUBPARTITION</literal>
+ clauses were output on a single line, making it difficult to
+ read or parse.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="AUTO_INCREMENT"/>
+ <manual type="UPDATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40176"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For a partitioned table having an
+ <literal>AUTO_INCREMENT</literal> column: If the first statement
+ following a start of the server or a <literal>FLUSH
+ TABLES</literal> statement was an <literal>UPDATE</literal>
+ statement, the <literal>AUTO_INCREMENT</literal> column was not
+ incremented correctly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="InnoDB"/>
+ <manual type="ORDER BY"/>
+ <manual type="indexes"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37721"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When executing an <literal>ORDER BY</literal> query on a
+ partitioned <literal>InnoDB</literal> table using an index that
+ was not in the partition expression, the results were sorted on
+ a per-partition basis rather than for the table as a whole.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="ALTER TABLE"/>
+ <manual type="ANALYZE PARTITION"/>
+ <manual type="CHECK PARTITION"/>
+ <manual type="OPTIMIZE PARTITION"/>
+ <manual type="REORGANIZE PARTITION"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39434"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server attempted to execute the statements <literal>ALTER
+ TABLE ... ANALYZE PARTITION</literal>, <literal>ALTER TABLE ...
+ CHECK PARTITION</literal>, <literal>ALTER TABLE ... OPTIMIZE
+ PARTITION</literal>, and <literal>ALTER TABLE ... REORGANIZE
+ PARTITION</literal> on tables that were not partitioned.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <highlight type="replication"/>
+ <manual type="InnoDB"/>
+ <manual type="transaction isolation level"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39084"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Changing the transaction isolation level while replicating
+ partitioned <literal>InnoDB</literal> tables could cause
+ statement-based logging to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="CREATE TABLE IF NOT EXISTS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37921"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.28-ndb-6.3.18"/>
+ </versions>
+
+ <message>
+
+ <para>
+ After a forced shutdown and initial restart of the cluster, it
+ was possible for SQL nodes to retain <filename>.FRM</filename>
+ files corresponding to <literal>NDBCLUSTER</literal> tables that
+ had been dropped, and thus to be unaware that these tables no
+ longer existed. In such cases, attempting to re-create the
+ tables using <literal>CREATE TABLE IF NOT EXISTS</literal> could
+ fail with a spurious <errortext>Table ... doesn't
+ exist</errortext> error.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ReadCommitted"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40543"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It was theoretically possible for stale data to be read from
+ <literal>NDBCLUSTER</literal> tables when the transaction
+ isolation level was set to <literal>ReadCommitted</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="LockExecuteThreadToCPU"/>
+ <manual type="LockMaintThreadsToCPU"/>
+ <manual type="Solaris"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40521"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>LockExecuteThreadToCPU</literal> and
+ <literal>LockMaintThreadsToCPU</literal> parameters did not work
+ on Solaris.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="RBR"/>
+ <manual type="MyISAM"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40004"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Row-based replication failed with non-partitioned
+ <literal>MyISAM</literal> tables having no indexes.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="mysqldump"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40346"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Restoring a MySQL Cluster from a dump made using
+ <command>mysqldump</command> failed due to a spurious error:
+ <errortext>Can't execute the given command because you have
+ active locked tables or an active transaction</errortext>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40455"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The MGM API reset error codes on management server handles
+ before checking them. This meant that calling an MGM API
+ function with a null handle caused applications to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40457"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>SET SESSION ndb_optimized_node_selection = 1</literal>
+ failed with an invalid warning message.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="checkpoints"/>
+ <manual type="DBDIH"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40370"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A restarting data node could fail with an error in the
+ <literal>DBDIH</literal> kernel block when a local or global
+ checkpoint was started or triggered just as the node made a
+ request for data from another data node.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="backups"/>
+ <manual type="O_DIRECT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40205"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>O_DIRECT</literal> was incorrectly disabled when making
+ MySQL Cluster backups.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="compiling"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37491"/>
+ <seealsobug bugid="40238"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The NDB API example programs included in MySQL Cluster source
+ distributions failed to compile.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="TEXT"/>
+ <manual type="query cache"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39295"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The MySQL Query Cache did not function correctly with
+ <literal>NDBCLUSTER</literal> tables containing
+ <literal role="type">TEXT</literal> columns.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="diskdata"/>
+ <manual type="O_SYNC"/>
+ <manual type="O_DIRECT"/>
+ <manual type="Solaris"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34638"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>O_SYNC</literal> was incorrectly disabled on platforms
+ that do not support <literal>O_DIRECT</literal>. This issue was
+ noted on Solaris but could have affected other platforms not
+ having <literal>O_DIRECT</literal> capability.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="error messages"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28496"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Error messages for <literal>NDBCLUSTER</literal> error codes
+ 1224 and 1227 were missing.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="transactions"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32656"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A duplicate key error raised when inserting into an
+ <literal>NDBCLUSTER</literal> table caused the current
+ transaction to abort, after which any SQL statement other than a
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ failed. With this fix, the <literal>NDBCLUSTER</literal> storage
+ engine now supports rollback of individual statements in such
+ cases, and it is no longer necessary to issue an explicit
+ <literal role="stmt" condition="commit">ROLLBACK</literal> and
+ then retry the entire transaction.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <manual type="Falcon"/>
+ <manual type="INFORMATION_SCHEMA"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29211"/>
+ <fixes bugid="34705"/>
+ <fixes bugid="34706"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>INFORMATION_SCHEMA.FALCON_TABLES</literal> table
+ has been removed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="falcon_record_chill_threshold"/>
+ <manual type="falcon_index_chill_threshold"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34486"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>SET GLOBAL falcon_record_chill_threshold</literal> and
+ <literal>SET GLOBAL falcon_index_chill_threshold</literal> did
+ not work.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="CREATE TABLE"/>
+ <manual type="page cache"/>
+ <manual type="startup"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34085"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>CREATE TABLE ... ENGINE=Falcon</literal> failed with an
+ unhelpful error message when the <literal>Falcon</literal>
+ storage engine had failed to allocate the page cache properly on
+ server startup. Now, <literal>Falcon</literal> is initialized on
+ server startup, and is not loaded if the allocation fails.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="tablespaces"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33723"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If <literal role="stmt">CREATE TABLE</literal> or
+ <literal role="stmt">ALTER TABLE</literal> of a
+ <literal>Falcon</literal> table failed, it was not possible to
+ create another table in the same database having the same name
+ unless the server was restarted. In some cases, subsequent
+ <literal role="stmt">CREATE TABLE</literal> statements could
+ cause the server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="Falcon"/>
+ <manual type="tablespaces"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33404"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Partition-level <literal>TABLESPACE</literal> options were
+ ignored for <literal>Falcon</literal> tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="serial log"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39025"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Falcon</literal> key pages were written to the serial
+ log in the wrong order. This had the potential to cause problems
+ if a failure of the server occurred during recovery.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="Solaris"/>
+ <manual type="mysql_install_db"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38843"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Solaris platforms, when the server was built with
+ <literal>Falcon</literal> support and the data directory set in
+ user's home directory, <command>mysql_install_db</command>
+ failed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="SPARC"/>
+ <manual type="compiling"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38766"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When built with <literal>Falcon</literal> support on 64-bit
+ SPARC platforms, <command>mysqld</command> hung on startup. This
+ occurred whether Sun Studio or <command>gcc</command> was used
+ to compile the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="error codes"/>
+ <manual type="duplicate key"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38719"/>
+ <seealsobug bugid="28842"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A duplicate key error raised when inserting into a partitioned
+ table used a different error code from that returned by such an
+ error raised when inserting into a table that was not
+ partitioned.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="multi-range read scans"/>
+ <manual type="IS [NOT] NULL"/>
+ <manual type="LQH"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38204"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Certain multi-range scans involving <literal>IS NULL</literal>
+ and <literal>IS NOT NULL</literal> comparisons failed with an
+ error in the <literal>NDB</literal> local query handler.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="NdbScanFilter"/>
+ <manual type="NdbScanOperation"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37986"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Creating an <literal>NdbScanFilter</literal> object using an
+ <literal>NdbScanOperation</literal> object that had not yet had
+ its <literal>readTuples()</literal> method called resulted in a
+ crash when later attempting to use the
+ <literal>NdbScanFilter</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="NdbRecord"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37672"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Executing an <literal>NdbRecord</literal> interpreted delete
+ created with an <literal>ANYVALUE</literal> option caused the
+ transaction to abort.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndbd"/>
+ <manual type="node restart"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38580"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.28-ndb-6.3.18"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When restarting a data node, an excessively long shutodwn
+ message could cause the node process to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="mysqld"/>
+ <manual type="--ndbcluster option"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39635"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.28-ndb-6.3.18"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Starting the MySQL Server with the <option>--ndbcluster</option>
+ option plus an invalid command-line option (for example, using
+ <command>mysqld</command> <option>--ndbcluster
+ --foobar</option>) caused it to hang while shutting down the
+ binlog thread.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="compiling"/>
+ <manual type="Sun Studio"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39451"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The Sun Studio compiler failed to build debug versions of the
+ server due to use of features specific to
+ <command>gcc</command>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="CREATE TABLESPACE"/>
+ <manual type="DROP TABLESPACE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38186"/>
+ <fixes bugid="38743"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>CREATE TABLESPACE</literal> failed when invoked
+ immediately following a <literal>DROP TABLESPACE</literal>
+ statement that used the same tablespace name.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="compiling"/>
+ <manual type="Sun Studio"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37603"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ mysqld failed to build using the Sun Studio compiler.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="compiling"/>
+ <manual type="Solaris"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36486"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server could not be compiled with <literal>Falcon</literal>
+ support on Solaris/x86.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="DROP TABLE"/>
+ <manual type="DROP TABLESPACE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36396"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Dropping a <literal>Falcon</literal> tablespace concurrently
+ with dropping a table using that tablespace caused the server to
+ crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="compiling"/>
+ <manual type="Sun Studio"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35929"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ MySQL could not be built using Sun Studio due to the use of
+ compiler options specific to <command>gcc</command>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="UPDATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34778"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Repeated <literal role="stmt">UPDATE</literal> operations on a
+ <literal>Falcon</literal> table could cause a memory leak.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="ALTER TABLE"/>
+ <manual type="temporary tables"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34567"/>
+ <introducedby bugid="33634"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Concurrent <literal role="stmt">ALTER TABLE</literal> operations
+ on temporary and non-temporary <literal>Falcon</literal> tables
+ caused the server to hang.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="BACKUP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33575"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Shutting down the MySQL Server immediately following the
+ execution of a <literal role="stmt">BACKUP DATABASE</literal>
+ statement caused the server to crash if the database to be
+ backed up contained any <literal>Falcon</literal> tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="tablespaces"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33517"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Table recovery failed repeatedly after starting the server with
+ a corrupted <literal>Falcon</literal> tablespace, causing the
+ server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="compiling"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32287"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On all x86 platforms, the default was to attempt to build the
+ server with the <literal>Falcon</literal> storage engine, even
+ if <literal>Falcon</literal> was not supported for a given
+ platform.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ <manual type="GROUP BY"/>
+ <manual type="aggregate functions"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37348"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The combination of a subquery with a <literal>GROUP
+ BY</literal>, an aggregate function calculated outside the
+ subquery, and a <literal>GROUP BY</literal> on the outer
+ <literal role="stmt">SELECT</literal> could cause the server to
+ crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="DDL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39885"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Heavy DDL usage caused the <command>mysqld</command> processes
+ to hang due to a timeout error (<literal>NDB</literal> error
+ code 266).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="EXPLAIN"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39872"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Executing <literal>EXPLAIN SELECT</literal> on an
+ <literal>NDBCLUSTER</literal> table could cause
+ <command>mysqld</command> to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="transactions"/>
+ <manual type="constraints"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="395638"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.3.18"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When a transaction included a multi-row insert to an
+ <literal>NDBCLUSTER</literal> table that caused a constraint
+ violation, the transaction failed to roll back.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="NdbInterpretedCode::add_val()"/>
+ <manual type="NdbInterpretedCode::sub_val()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39536"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.28-ndb-6.3.18"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Passing a value greater than 65535 to
+ <literal>NdbInterpretedCode::add_val()</literal> and
+ <literal>NdbInterpretedCode::sub_val()</literal> caused these
+ methods to have no effect.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="compiling"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36400"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Compiling the server with <literal>Falcon</literal> support
+ failed on Solaris 10 for x86 platforms failed due to use of
+ assembler code specific to <command>gcc</command>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="compiling"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36368"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Attempting to compile the server with Falcon support using the
+ Sun Studio 12 compiler failed with the error
+ <errortext>"Value.h", line 185: Error: A union member cannot
+ have a user-defined assignment operator</errortext>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="INSERT"/>
+ <manual type="tablespaces"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36294"/>
+ <fixes bugid="36367"/>
+ <seealsobug bugid="29648"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Following a number of <literal>INSERT ... SELECT</literal>
+ statements on a <literal>Falcon</literal> table, creating a
+ second <literal>Falcon</literal> table using the same tablespace
+ as the table into which the inserts were made and then
+ performing a simple <literal role="stmt">INSERT</literal> on the
+ new table caused the server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="SELECT"/>
+ <manual type="LIKE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36097"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A <literal>SELECT ... LIKE</literal> query issued following a
+ number of <literal role="stmt">INSERT</literal> statements on a
+ <literal>Falcon</literal> table failed to return all matching
+ records.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="TRUNCATE"/>
+ <manual type="transactions"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35991"/>
+ <seealsobug bugid="22165"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Executing <literal role="stmt">TRUNCATE</literal> statements
+ with interleaving transactions could cause
+ <command>mysqld</command> to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="ALTER TABLE"/>
+ <manual type="tablespaces"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33397"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An <literal>ALTER TABLE ... TABLESPACE</literal> statement
+ referencing a nonexistant tablespace on a
+ <literal>Falcon</literal> table failed with an inappropriate
+ error message the first time it was executed. A second attempt
+ to execute the statement led to a crash of the MySQL server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="tablespaces"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33607"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It was possible for multiple <command>mysqld</command> instances
+ to use the same <literal>Falcon</literal> tablespace and
+ metadata files, which could lead to corruption of the tablespace
+ files, metadata files, or both.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="INSERT"/>
+ <manual type="concurrency"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34990"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Two different threads could obtain the same record number for
+ concurrent inserts into the same <literal>Falcon</literal>
+ table.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="SELECT"/>
+ <manual type="multiple threads"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35932"/>
+ <fixes bugid="36410"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Multiple threads executing repeated queries on the same
+ <literal>Falcon</literal> table led eventually to a crash of the
+ server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <manual type="Falcon"/>
+ <manual type="upgrades"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35190"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Previously, <literal>Falcon</literal> failed silently when
+ attempting to read incompatible datafiles created by an earlier
+ version of the storage engine. Now, when
+ <literal>Falcon</literal> encounters such datafiles, it refuses
+ to start, and an appropriate error is issued instead.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="NFS"/>
+ <manual type="Linux 2.4"/>
+ <manual type="O_DIRECT"/>
+ <manual type="CREATE TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33484"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>CREATE TABLE ... ENGINE=Falcon</literal> failed on
+ kernel 2.4 based Linux systems when using
+ <literal>O_DIRECT</literal> with an NFS filesystem.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="UPDATE"/>
+ <manual type="COMMIT"/>
+ <manual type="ROLLBACK"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38947"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Falcon</literal> could hang trying to perform an
+ <literal role="stmt">UPDATE</literal> in one transaction while
+ waiting for another transaction to be committed or rolled back.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="tablespaces"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39138"/>
+ <seealsobug bugid="39789"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When recovering from a serial log containing many
+ <literal>CREATE TABLESPACE</literal> and <literal>DROP
+ TABLESPACE</literal> statements, <literal>Falcon</literal> could
+ lose data from tablespaces not referenced by these statements.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="memory management"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38519"/>
+ <seealsobug bugid="38770"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>Falcon</literal> memory manager did not always
+ perform initialization of internal objects correctly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="--datadir"/>
+ <manual type="embedded"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38770"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Falcon</literal> did not honor the
+ <option>--datadir</option> option and created its files in the
+ current directory instead. This error was apparent only when
+ running the embedded version of MySQL.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="ADD INDEX"/>
+ <manual type="DROP INDEX"/>
+ <manual type="DML"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38044"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Concurrent adding or dropping of indexes and execution of DML
+ statements on a <literal>Falcon</literal> table could cause the
+ server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="DROP TABLE"/>
+ <manual type="CREATE TABLE"/>
+ <manual type="ADD KEY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38039"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Dropping and re-creating a <literal>Falcon</literal> table, then
+ adding indexes to the re-created table, could cause spurious
+ errors or possibly a crash of the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="CREATE DATABASE"/>
+ <manual type="DROP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39613"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.28-ndb-6.3.18"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Dropping and then re-creating a database on one SQL node caused
+ other SQL nodes to hang.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="autodiscovery"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39612"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.28-ndb-6.3.18"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It is no longer a requirement for database autodiscovery that an
+ SQL node already be connected to the cluster at the time that a
+ database is created on another SQL node. It is no longer
+ necessary to issue <literal role="stmt">CREATE
+ DATABASE</literal> (or
+ <literal role="stmt" condition="create-database">CREATE
+ SCHEMA</literal>) statements on an SQL node joining the cluster
+ after a database is created in order for the new SQL node to see
+ the database and any <literal>NDCLUSTER</literal> tables that it
+ contains.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="transactions"/>
+ <manual type="DROP TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36438"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When one MySQL client application committed a transaction
+ affecting a <literal>Falcon</literal> table at the same time
+ that another client dropped this table, the
+ <literal role="stmt">DROP TABLE</literal> statement did not
+ <quote>see</quote> that transaction. This led to a situation
+ such that a row affected by the transaction was later accessed
+ in a manner that referred to the deleted table, resulting in a
+ crash of the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="PRIMARY KEY"/>
+ <manual type="INSERT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39267"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.28-ndb-6.3.18"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Unique identifiers in tables having no primary key were not
+ cached. This fix has been observed to increase the efficiency of
+ <literal role="stmt">INSERT</literal> operations on such tables
+ by as much as 50%.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="INSERT"/>
+ <manual type="DELETE"/>
+ <manual type="concurrency"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33933"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In some cases, concurrent <literal role="stmt">INSERT</literal>
+ and <literal role="stmt">DELETE</literal> statements on the same
+ <literal>Falcon</literal> table could cause the server to crash,
+ due to a failure to find a record that should have been in the
+ table.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="falcon_consistent_read"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33041"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It was not possible to set the value of
+ <literal>falcon_consistent_read</literal> within the local
+ scope. You can now set the global value, using
+ <literal role="stmt" condition="set-option">SET
+ GLOBAL</literal>, but this affects only the current local scope
+ and all new connections made after the global variable was set.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="SPARC"/>
+ <manual type="compiling"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38891"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It was not possible to build the server with
+ <literal>Falcon</literal> support on SPARC when using the Sun
+ Studio compiler.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="LIMIT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37726"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Executing large numbers of SQL statements using
+ <literal>LIMIT</literal> on <literal>Falcon</literal> tables
+ eventually led to a crash of the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="compiling"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37725"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ MySQL server binaries built using <command>gcc4.3</command>
+ could crash when running large numbers of DML statements on
+ <literal>Falcon</literal> tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="ALTER TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37072"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Executing <literal>ALTER TABLE ADD PARTITION</literal> followed
+ by <literal>ALTER TABLE DROP PARTITION</literal> on a Falcon
+ table, and then killing the thread performing these statements
+ could cause the server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34351"/>
+ <seealsobug bugid="29151"/>
+ <seealsobug bugid="35321"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Inserting a unique record into a <literal>Falcon</literal>
+ table, then performing a <literal role="stmt">DELETE</literal>
+ on the same record resulted in the error <errortext>Record has
+ changed since last read</errortext>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="ALTER TABLE"/>
+ <manual type="DML"/>
+ <manual type="deadlock"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38043"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Executing <literal role="stmt">ALTER TABLE</literal> and DML
+ statements concurrently on <literal>Falcon</literal> tables
+ could cause the server to hang.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="ALTER TABLE"/>
+ <manual type="ADD KEY"/>
+ <manual type="DROP KEY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38041"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>ALTER TABLE ... ADD KEY</literal> and <literal>ALTER
+ TABLE ... DROP KEY</literal> were not always handled correctly
+ for <literal>Falcon</literal> tables, resulting in spurious
+ duplicate key and other errors.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="SELECT"/>
+ <manual type="AVG()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37344"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A large number of updates on a <literal>Falcon</literal> table
+ followed by a query of the form <literal>SELECT
+ AVG(<replaceable>int_non_key_column</replaceable>) FROM
+ <replaceable>table</replaceable> WHERE
+ <replaceable>int_non_key_column</replaceable> <
+ <replaceable>constant</replaceable> GROUP BY
+ <replaceable>int_key_column</replaceable> LIMIT
+ <replaceable>limit</replaceable></literal> could crash the
+ server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="falcon_page_size"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37343"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Queries with complex conditions in the <literal>WHERE</literal>
+ clause on <literal>Falcon</literal> tables when
+ <literal>falcon_page_size</literal> was set to a low value could
+ cause the server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="Solaris"/>
+ <manual type="mysql_install_db"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36745"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql_install_db</command> from a
+ <literal>Falcon</literal>-enabled build crashed on
+ Solaris/SPARC.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="compiling"/>
+ <manual type="DTrace"/>
+ <manual type="Solaris"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36403"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Compiling the server with <literal>Falcon</literal> support
+ failed on Solaris 10 due to problems with DTrace. This occurred
+ even when the build was configured using
+ <option>--disable-dtrace</option>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="LOAD DATA INFILE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35982"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Concurrent <literal role="stmt" condition="load-data">LOAD DATA
+ INFILE</literal> statements inserting data into
+ <literal>Falcon</literal> tables could crash the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="views"/>
+ <manual type="updates"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35322"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Simultaneous inserts and updates on an updateable view
+ referencing a <literal>Falcon</literal> table could sometimes
+ cause duplicate key errors.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="rollback"/>
+ <manual type="DDL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38933"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Trying to execute a DDL statement on a <literal>Falcon</literal>
+ table while a transaction was being rolled back could cause the
+ server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <manual type="DROP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39404"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.28-ndb-6.3.18"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In some cases, dropping a database on the master could cause
+ table logging to fail on the slave, or, when using a debug
+ build, could cause the slave <command>mysqld</command> to fail
+ completely.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="PRIMARY KEY"/>
+ <manual type="DELETE"/>
+ <manual type="UPDATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37153"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.3.18"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A statement of the form <literal>DELETE FROM
+ <replaceable>table</replaceable> WHERE
+ <replaceable>primary_key</replaceable>=<replaceable>value</replaceable></literal>
+ or <literal>UPDATE <replaceable>table</replaceable> WHERE
+ <replaceable>primary_key</replaceable>=<replaceable>value</replaceable></literal>
+ where there was no row whose primary key column had the stated
+ <replaceable>value</replaceable> appeared to succeed, with the
+ server reporting that 1 row had been changed.
+ </para>
+
+ <para>
+ This issue was only known to affect MySQL Cluster NDB 6.3.11 and
+ later NDB 6.3 versions.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="MaxNoOfLocalScans"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39549"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.28-ndb-6.3.18"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Setting a low value of <literal>MaxNoOfLocalScans</literal>
+ (< 100) and performing a large number of (certain) scans
+ could cause the Transaction Coordinator to run out of scan
+ fragment records, and then crash. Now when this resource is
+ exhausted, the cluster returns Error 291 (<errortext>Out of
+ scanfrag records in TC (increase MaxNoOfLocalScans)</errortext>)
+ instead.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="UNIQUE"/>
+ <manual type="SUMA"/>
+ <manual type="SUB_CREATE_REF"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39518"/>
+ <seealsobug bugid="39450"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.28-ndb-6.3.18"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Creating a unique index on an <literal>NDBCLUSTER</literal>
+ table caused a memory leak in the <literal>NDB</literal>
+ subscription manager (<literal>SUMA</literal>) which could lead
+ to mysqld hanging, due to the fact that the resource shortage
+ was not reported back to the <literal>NDB</literal> kernel
+ correctly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38798"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Server code used in binary logging could in some cases be
+ invoked even though binary logging was not actually enabled,
+ leading to asserts and other server errors.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="UPDATE"/>
+ <manual type="INSERT"/>
+ <manual type="transactions"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32709"/>
+ <seealsobug bugid="38262"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A statement did not always commit or roll back correctly when
+ the server was shut down; the error could be triggered by having
+ a failing <literal role="stmt">UPDATE</literal> or
+ <literal role="stmt">INSERT</literal> statement on a
+ transactional table, causing an implicit rollback.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <highlight type="replication"/>
+ <manual type="binlog_format"/>
+ <manual type="RBR"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39106"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="priv">SUPER</literal> privilege is now
+ required to change the session value of
+ <literal role="sysvar">binlog_format</literal> as well as its
+ global value. For more information about
+ <literal role="sysvar">binlog_format</literal>, see
+ <xref linkend="replication-formats"/>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="RBR"/>
+ <manual type="mysqlbinlog"/>
+ <manual type="--replicate-* options"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36099"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Replication filtering rules were inappropiately applied when
+ executing <literal role="stmt">BINLOG</literal> pseudo-queries.
+ One way in which this problem showed itself was that, when
+ replaying a binary log with <command>mysqlbinlog</command>, RBR
+ events were sometimes not executed if the
+ <option>--replicate-do-db</option> option was specified. Now
+ replication rules are applied only to those events executed by
+ the slave SQL thread.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="ALTER TABLE"/>
+ <manual type="ENGINE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35765"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When an attempt is made to change a table to an unsupported
+ storage engine, the server normally uses the default storage
+ engine in place of the requested engine while issuing a warning.
+ However, if the table was partitioned, the same
+ <literal role="stmt">ALTER TABLE</literal> statement failed with
+ the error, <errortext>The mix of handlers in the partitions is
+ not allowed in this version of MySQL</errortext>. This happened
+ even if the server was not running in
+ <literal>NO_ENGINE_SUBSTITUTION</literal> mode. Now the behavior
+ for partitioned tables is the same as for other MySQL tables;
+ the substitution is made, and a warning is issued.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="libmysqld"/>
+ <manual type="NDB table events"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39450"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.3.18"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Embedded <command>libmysqld</command> with
+ <literal>NDB</literal> did not drop table events.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <highlight type="packaging"/>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Support for the <literal>InnoDB</literal> storage engine was
+ missing from the GPL source releases. An updated GPL source
+ tarball
+ <filename>mysql-5.1.27-ndb-6.3.17-innodb.tar.gz</filename> which
+ includes code for building <literal>InnoDB</literal> can be
+ found on
+ <ulink url="ftp://ftp.mysql.com/pub/mysql/download/cluster_telco/mysql-5.1.27-ndb-6.3.17/">the
+ MySQL FTP site</ulink>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38791"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Support for multi-range index scans using the old API (using,
+ for example,
+ <literal>NdbIndexScanOperation::setBound()</literal> or
+ <literal>NdbIndexScanOperation::end_of_bound()</literal>) were
+ dropped in MySQL Cluster NDB 6.2. This functionality is restored
+ in MySQL Cluster NDB 6.3 beginning with 6.3.17, but remains
+ unavailable in MySQL Cluster NDB 6.2. Both MySQL Cluster NDB 6.2
+ and 6.3 support multi-range scans via the
+ <literal>NdbRecord</literal> API.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="NdbScanOperation::readTuples()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38717"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>NdbScanOperation::readTuples()</literal> method
+ could be called multiple times without error.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="building"/>
+ <manual type="headers"/>
+ <manual type="warnings"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38177"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Problems with the public headers prevented
+ <literal>NDB</literal> applications from being built with
+ warnings turned on.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <manual type="restart"/>
+ <manual type="subscriptions"/>
+ <manual type="SUMA_START_ME"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38767"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ During a parallel node restart, the starting nodes could
+ (sometimes) incorrectly synchronize subscriptions among
+ themselves. Instead, such this synchronization now takes places
+ only among nodes that have actually (completely) started.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="mutex"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39158"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>MgmtSrvr::allocNodeId()</literal> left a mutex locked
+ following an <errortext>Ambiguity for node if %d</errortext>
+ error.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="mysql-test-run.pl"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39026"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An invalid path specification caused
+ <command>mysql-test-run.pl</command> to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="DBTC"/>
+ <manual type="LOG_COMMIT"/>
+ <manual type="LQH_TRANS_CONF"/>
+ <manual type="node failure"/>
+ <manual type="TC"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38930"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ During transactional coordinator takeover (directly after node
+ failure), the LQH finding an operation in the
+ <literal>LOG_COMMIT</literal> state sent an
+ <literal>LQH_TRANS_CONF</literal> signal twice, causing the TC
+ to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_mgmd"/>
+ <manual type="Solaris"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38628"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An invalid memory access caused the management server to crash
+ on Solaris Sparc platforms.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndbd"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38609"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A segfault in <literal>Logger::Log</literal> caused
+ <command>ndbd</command> to hang indefinitely.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_mgmd"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38592"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>ndb_mgmd</command> failed to start on older Linux
+ distributions (2.4 kernels) that did not support e-polling.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_mgmd"/>
+ <manual type="network"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38563"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>ndb_mgmd</command> sometimes performed unnecessary
+ network I/O with the client. This in combination with other
+ factors led to long-running threads that were attempting to
+ write to clients that no longer existed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_restore"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38520"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>ndb_restore</command> failed with a floating point
+ exception due to a division by zero error when trying to restore
+ certain data files.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_mgmd"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38424"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A failed connection to the management server could cause a
+ resource leak in <command>ndb_mgmd</command>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="configuration"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38380"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Failure to parse configuration parameters could cause a memory
+ leak in the NDB log parser.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="RENAME"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36658"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Renaming an <literal>NDBCLUSTER</literal> table on one SQL node,
+ caused a trigger on this table to be deleted on another SQL
+ node.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="UNIQUE INDEX"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35599"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Attempting to add a <literal>UNIQUE INDEX</literal> twice to an
+ <literal>NDBCLUSTER</literal> table, then deleting rows from the
+ table could cause the MySQL Server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_restore"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33801"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>ndb_restore</command> failed when a single table was
+ specified.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="GCP"/>
+ <manual type="node failure"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30780"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27-ndb-6.3.17"/>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>GCP_COMMIT</literal> did not wait for transaction
+ takeover during node failure. This could cause
+ <literal>GCP_SAVE_REQ</literal> to be executed too early. This
+ could also cause (very rarely) replication to skip rows.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="importantnote"/>
+ <manual type="maria"/>
+ <manual type="--old"/>
+ <manual type="CHECKSUM TABLE"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.25-maria"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The behavior of <literal role="stmt">CHECKSUM TABLE</literal>
+ has been modified so that the checksum operates consistently
+ within all engines by default, unless you use the
+ <option>--old</option> option.
+ </para>
+
+ <para>
+ If you run <command>mysqld</command> <option>--old</option>
+ option, then:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ If table is <literal>MyISAM</literal> with an old-style
+ checksum (5.0), then <literal role="stmt">CHECKSUM
+ TABLE</literal> returns the 5.0 checksum.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If the <literal>QUICK</literal> option is specified to
+ <literal role="stmt">CHECKSUM TABLE</literal>,
+ <literal>NULL</literal> is returned instead.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ When the <literal>EXTENDED</literal> option is specified,
+ the checksum is calculated by looping over all the rows and
+ calculates the checksum using the 5.0 algorithm.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ If you run <command>mysqld</command> without the
+ <option>--old</option> option, then:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ If the table is <literal>MyISAM</literal> with the new-style
+ live checksum (5.1), then the live checksum is returned.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If the <literal>QUICK</literal> option to <literal>OPTIMIZE
+ TBLE</literal>, <literal>NULL</literal> is returned.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ When the <literal>EXTENDED</literal> option is specified,
+ the checksum is calculated by looping over all the rows and
+ calculating the checksum using the 5.1 algorithm.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ In addition, if you run <literal role="stmt">CHECKSUM
+ TABLE</literal> on <literal>MyISAM</literal> tables with
+ <literal role="type">VARCHAR</literal> columns, using
+ <literal>ROW_FORMAT=fixed</literal> and row-level checksums
+ enabled, then a warning will be raised that the table must be
+ repaired using <literal role="stmt">REPAIR TABLE</literal> to
+ build the new checksum.
+ </para>
+
+ <para>
+ To ensure that tables moved from a MySQL 5.1 environment to
+ MySQL 5.1-maria, or MySQL 6.0 environment, you should run
+ <command>mysqld</command> with the <option>--old</option> and
+ run <literal>CHECKSUM TABLE ... EXTENDED</literal> to compare
+ using the 5.0 algorithm.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="importantnote"/>
+ <manual type="maria"/>
+ <manual type="temporary tables"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.27-maria"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When MySQL is built with the <literal>Maria</literal> engine,
+ all internal temporary on disk tables will use the
+ <literal>Maria</literal> engine. Using <literal>Maria</literal>
+ temporary tables in plkace of <literal>MyISAM</literal> tables
+ should result in a performance gain.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37051"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The
+ <option>--replicate-<replaceable>*</replaceable>-table</option>
+ options were not evaluated correctly when replicating
+ multi-table updates.
+ </para>
+
+ <para>
+ As a result of this fix, replication of multi-table updates no
+ longer fails when an update references a missing table but does
+ not update any of its columns.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="DROP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38773"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Issuing a <literal role="stmt">DROP DATABASE</literal> while any
+ temporary tables were open caused the server to switch to
+ statement-based mode.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <highlight type="incompatiblechange"/>
+ <manual type="Mac OS X"/>
+ <manual type="names"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37402"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Mac OS X with <literal>lower_case_table_names = 2</literal>,
+ the server could not read partitioned tables whose names
+ contained uppercase letters.
+ </para>
+
+ <para>
+ Partitioned tables using mixed case names should be renamed or
+ dropped before upgrading to this version of the server on Mac OS
+ X.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="RBR"/>
+ <manual type="INSTALL PLUGIN"/>
+ <manual type="UNINSTALL PLUGIN"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35807"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">INSTALL PLUGIN</literal> and
+ <literal role="stmt">UNINSTALL PLUGIN</literal> caused row-based
+ replication to fail.
+ </para>
+
+ <note>
+ <para>
+ These statements are not replicated; however, when using
+ row-based logging, the changes they introduce in the
+ <literal>mysql</literal> system tables are written to the
+ binary log.
+ </para>
+ </note>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="TIMESTAMP"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38272"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When a partitioned table had a
+ <literal role="type">TIMESTAMP</literal> column defined with
+ <literal>CURRENT_TIMESTAMP</literal> as the default but with no
+ <literal>ON UPDATE</literal> clause, the column's value was
+ incorrectly set to <literal>CURRENT_TIMESTAMP</literal> when
+ updating across partitions.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="replication"/>
+ <highlight type="importantchange"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.12"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The default value for the <option>--binlog-format</option>
+ server option is now <literal>MIXED</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="Upgrade"/>
+ <manual type="MySQL Instance Configuration Wizard"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31674"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When upgrading from MySQL 5.1.19 to any version between MySQL
+ 5.1.20 to MySQL 5.1.23, the MySQL Instance Configuration Wizard
+ would fail to account for the change in name for the
+ <command>mysqld-nt.exe</command> to
+ <command>mysqld.exe</command>, causing MySQL to fail to start
+ properly after the upgrade.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="MySQL Instance Configuration Wizard"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27013"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ <version ver="5.1.24"/>
+ <version ver="5.0.60"/>
+ <version ver="4.1.25"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The MySQL Instance Configuration Wizard would not allow you to
+ choose a service name, even though the criteria for the service
+ name were valid. The code that checks the name has been updated
+ to support the correct criteria of any string less than 256
+ character and not containing either a forward or backward slash
+ character.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33211"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When creating temporary tables within <literal>Falcon</literal>,
+ the tables are automatically created in the
+ <literal>FALCON_TEMPORARY</literal> tablespace. If you specify
+ an alternate tablespace to the <literal role="stmt">CREATE
+ TABLE</literal> statement a warning will now be issued to that
+ effect.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <highlight type="replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29371"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A new configuration option, <literal>falcon_support_xa</literal>
+ has been added. The option specifies whether
+ <literal>Falcon</literal> should report itself as a two-phase
+ commit storage engine, and therefore take part in XA
+ transactions.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <highlight type="replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36468"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Replicating a Falcon table that contained a
+ <literal role="type">TEXT</literal> or
+ <literal role="type">BLOB</literal> column would fail during a
+ <literal role="stmt">DELETE</literal> operation with the error
+ <literal>HA_ERR_END_OF_FILE</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="SSL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37517"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Building MySQL with SSL and <literal>Falcon</literal> enabled
+ would lead to a build failure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="INFORMATION_SCHEMA"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33141"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The columns in the <literal>INFORMATION_SCHEMA</literal> table
+ for <literal>FALCON_SERIAL_LOG_INFO</literal>,
+ <literal>FALCON_TRANSACTIONS</literal>, and
+ <literal>FALCON_TRANSACTION_SUMMARY</literal> contained a
+ reference to the databae of tablespace, but the column
+ information was actually showing instances of the
+ <literal>Falcon</literal> engine. The tables have been updated
+ to a different structure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="UUID()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35848"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="func">UUID()</literal> function returned
+ UUIDs with the wrong time; this was because the offset for the
+ time part in UUIDs was miscalculated.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqlbinlog"/>
+ <manual type="temporary files"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35543"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.66"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqlbinlog</command> left temporary files on the disk
+ after shutdown, leading to the pollution of the temporary
+ directory, which eventually caused
+ <command>mysqlbinlog</command> to fail. This caused problems in
+ testing and other situations where
+ <command>mysqlbinlog</command> might be invoked many times in a
+ relatively short period of time.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="Falcon"/>
+ <manual type="autocommit"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37221"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When <literal role="sysvar">autocommit</literal> was set equal
+ to <literal>1</literal> after starting a transaction, the binary
+ log did not commit the outstanding transaction. The reason this
+ happened was that the binary log commit function saw only the
+ values of the new settings, and decided that there was nothing
+ to commit.
+ </para>
+
+ <para>
+ This issue was first observed when using the
+ <literal>Falcon</literal> storage engine, but it is possible
+ that it affected other storage engines as well.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37150"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.66"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some kinds of internal errors, such as <errortext>Out of
+ memory</errortext> errors, could cause the server to crash when
+ replicating statements with user variables.
+ </para>
+
+ <para>
+ certain internal errors.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="TIMESTAMP"/>
+ <manual type="RBR"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37076"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Row-based replication did not correctly copy
+ <literal role="type">TIMESTAMP</literal> values from a
+ big-endian storage engine to a little-endian storage engine.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="PARTITION BY LIST"/>
+ <manual type="NOT IN"/>
+ <manual type="MyISAM"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35931"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A <literal>LIST</literal> partitioned <literal>MyISAM</literal>
+ table returned erroneous results when an index was present on a
+ column in the <literal>WHERE</literal> clause and <literal>NOT
+ IN</literal> was used on that column.
+ </para>
+
+ <para>
+ Searches using the index were also much slower then if the index
+ were not present.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="storage engines"/>
+ <manual type="COUNT()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35745"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>SELECT COUNT(*)</literal> was not correct for some
+ partitioned tables using a storage engine that did not support
+ <literal>HA_STATS_RECORDS_IS_EXACT</literal>. Tables using the
+ <literal>ARCHIVE</literal> storage engine were known to be
+ affected.
+ </para>
+
+ <para>
+ This was because <literal>ha_partition::records()</literal> was
+ not implemented, and so the default
+ <literal>handler::records()</literal> was used in its place.
+ However, this is not correct behavior if the storage engine does
+ not support <literal>HA_STATS_RECORDS_IS_EXACT</literal>.
+ </para>
+
+ <para>
+ The solution was to implement
+ <literal>ha_partition::records()</literal> as a wrapper around
+ the underlying partition records.
+ </para>
+
+ <para>
+ As a result of this fix, the rows column in the output of
+ <literal>EXPLAIN PARTITIONS</literal> now includes the total
+ number of records in the partitioned table.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <manual type="Maria"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>Maria</literal> Storage Engine is now available as
+ standard. <literal>Maria</literal> is a crash safe version of
+ <literal>MyISAM</literal>. <literal>Maria</literal> supports all
+ of the main functionality of the <literal>MyISAM</literal>
+ engine, but includes recovery support (in the event of a system
+ crash), full logging (including <literal>CREATE</literal>,
+ <literal>DROP</literal>, <literal>RENAME</literal>, and
+ <literal role="stmt">TRUNCATE</literal> operations), all
+ <literal>MyISAM</literal> row formats and a new
+ <literal>Maria</literal>-specific row format.
+ <literal>Maria</literal> is documented at
+ <xref linkend="se-maria"/>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="XML"/>
+ <manual type="XPath"/>
+ <manual type="boolean()"/>
+ <manual type="NULL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26051"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The XPath <literal>boolean()</literal> function did not cast
+ string and nodeset values correctly in some cases. It now
+ returns <literal>TRUE</literal> for any non-empty string or
+ nodeset and 0 for a <literal>NULL</literal> string, as specified
+ in the XPath standard..
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="NdbBlob::setValue()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31284"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.16"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A buffer overrun in <literal>NdbBlob::setValue()</literal>
+ caused erroneous results on Mac OS X.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36375"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Closing a scan before it was executed caused the application to
+ segfault.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35876"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Scans having no bounds set were handled incorrectly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="libndbclient"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36124"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using NDB API applications from older MySQL Cluster versions
+ with <literal>libndbclient</literal> from newer ones caused the
+ cluster to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="libndbclient"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35927"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.14"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Accesing the debug version of <literal>libndbclient</literal>
+ via <literal>dlopen()</literal> resulted in a segmentation
+ fault.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <manual type="RESET MASTER"/>
+ <manual type="mysql.ndb_binlog_index"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34356"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.23-ndb-6.3.11"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">RESET MASTER</literal> now uses
+ <literal role="stmt">TRUNCATE</literal> rather than
+ <literal role="stmt">DELETE</literal> to clear the
+ <literal>mysql.ndb_binlog_index</literal> table. This improves
+ the performance of the statement and is less likely to leave the
+ table in a fragmented state.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="VARCHAR"/>
+ <manual type="VARBINARY"/>
+ <manual type="condition pushdown"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35393"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.15"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Where column values to be compared in a query were of the
+ <literal role="type">VARCHAR</literal> or
+ <literal role="type">VARBINARY</literal> types,
+ <literal>NDBCLUSTER</literal> passed a value padded to the full
+ size of the column, which caused unnecessary data to be sent to
+ the data nodes. This also had the effect of wasting CPU and
+ network bandwidth, and causing condition pushdown to be disabled
+ where it could (and should) otherwise have been applied.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="mysqld"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37628"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Failure of a data node could sometimes cause mysqld to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="DELETE"/>
+ <manual type="unique index"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37516"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>DELETE ... WHERE
+ <replaceable>unique_index_column</replaceable>=<replaceable>value</replaceable></literal>
+ deleted the wrong row from the table.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <manual type="log-slave-updates"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37472"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Data was written to the binlog with
+ <option>--log-slave-updates</option> disabled.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="subscriptions"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37442"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If subscription was terminated while a node was down, the epoch
+ was not properly acknowledged by that node.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="libmysqld"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37429"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>libmysqld</literal> failed to wait for the cluster
+ binlog thread to terminate before exiting.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="logging"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37427"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Event buffer lag reports are now written to the cluster log.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37338"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In rare circumstances, a connection followed by a disconnection
+ could give rise to a <quote>stale</quote> connection where the
+ connection still existed but was not seen by the transporter.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32949"/>
+ <fixes bugid="37279"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Creating a table on an SQL node, then starting an NDB API
+ application that listened for events from this table, then
+ dropping the table from an SQL node, prevented data node
+ restarts.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="NdbTransaction::execute()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37158"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When some operations succeeded and some failed following a call
+ to <literal>NdbTransaction::execute(Commit,
+ AO_IgnoreOnError)</literal>, a race condition could cause
+ spurious occurrences of NDB API Error 4011 (<errortext>Internal
+ error</errortext>).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="query cache"/>
+ <manual type="autocommit"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36692"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Queries against <literal>NDBCLUSTER</literal> tables were cached
+ only if <literal role="sysvar">autocommit</literal> was in use.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <highlight type="clusterapi"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35607"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Changing the system time on data nodes could cause MGM API
+ applications to hang and the data nodes to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="AUTO_INCREMENT"/>
+ <manual type="triggers"/>
+ <manual type="INSERT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36443"/>
+ <seealsobug bugid="33029"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.26"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Performing an insert on a table having an
+ <literal>AUTO_INCREMENT</literal> column and an
+ <literal role="stmt">INSERT</literal> trigger that was being
+ replicated from a master running MySQL 5.0 or any version of
+ MySQL 5.1 up to and including MySQL 5.1.11 to a slave running
+ MySQL 5.1.12 or later caused the replication slave to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_restore"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30452"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Added the <option>--no-binlog</option> option for
+ <command>ndb_restore</command>. When used, this option prevents
+ information being written to SQL node binary logs from the
+ restoration of a cluster backup.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="CREATE TABLE"/>
+ <manual type="ndbrequire()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37092"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.15"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Under some circumstances, a failed <literal role="stmt">CREATE
+ TABLE</literal> could mean that subsequent
+ <literal role="stmt">CREATE TABLE</literal> statements caused
+ node failures.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="CREATE TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37072"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.15"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A fail attempt to create an <literal>NDB</literal> table could
+ in some cases lead to resource leaks or cluster failures.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="NULL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37039"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.15"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Attempting to create a native backup of <literal>NDB</literal>
+ tables having a large number of <literal>NULL</literal> columns
+ and data could lead to node failures.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.15"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When dropping a table failed for any reason (such as when in
+ single user mode) then the corresponding
+ <filename>.ndb</filename> file was still removed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36851"/>
+ <seealsobug bugid="26756"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.15"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When an insert operation involving
+ <literal role="type">BLOB</literal> data was attempted on a row
+ which already existed, no duplicate key error was correctly
+ reported and the transaction is incorrectly aborted. In some
+ cases, the existing row could also become corrupted.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36843"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.15"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Checking of API node connections was not efficiently handled.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="DELETE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36756"/>
+ <seealsobug bugid="36851"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.15"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Attempting to delete a non-existent row from a table containing
+ a <literal role="type">TEXT</literal> or
+ <literal role="type">BLOB</literal> column within a transaction
+ caused the transaction to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="backup"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36044"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.15"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If the combined total of tables and indexes in the cluster was
+ greater than 4096, issuing <literal>START BACKUP</literal>
+ caused data nodes to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36950"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.15"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Ordered index scans were not pruned correctly where a
+ partitioning key was specified with an EQ-bound.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_size.pl"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="43022"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.15"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In certain rare situations, <filename>ndb_size.pl</filename>
+ could fail with the error <errortext>Can't use string
+ ("<replaceable>value</replaceable>") as a HASH ref while "strict
+ refs" in use</errortext>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="ALTER TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34604"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When one user was in the midst of a transaction on a partitioned
+ table, a second user performing an <literal role="stmt">ALTER
+ TABLE</literal> on this table caused the server to hang.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="INSERT"/>
+ <manual type="AUTO_INCREMENT"/>
+ <manual type="MyISAM"/>
+ <manual type="InnoDB"/>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33479"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Inserts failed on partitioned tables containing user-supplied
+ values for an <literal>AUTO_INCREMENT</literal> column.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="epoll"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36537"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.14"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A race condition caused by a failure in epoll handling could
+ cause data nodes to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36199"/>
+ <fixes bugid="36246"/>
+ <fixes bugid="36247"/>
+ <fixes bugid="36276"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.14"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Under certain rare circumstances, the failure of the new master
+ node while attempting a node takeover would cause takeover
+ errors to repeat without being resolved.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_schema"/>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35943"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.14"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When more than one SQL node connected to the cluster at the same
+ time, creation of the <literal>mysql.ndb_schema</literal> table
+ failed on one of them with an explicit <errortext>Table
+ exists</errortext> error, which was not necessary.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="mysql_upgrade"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35708"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.14"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqld</command> failed to start after running
+ <command>mysql_upgrade</command>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="NdbOperation::equal()"/>
+ <manual type="NdbOperation::setValue()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33747"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.14"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Attempting to pass a nonexistent column name to the
+ <literal>equal()</literal> and <literal>setValue()</literal>
+ methods of <literal>NdbOperation</literal> caused NDB API
+ applications to crash. Now the column name is checked, and an
+ error is returned in the event that the column is not found.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="x86_64"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29791"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.14"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Relocation errors were encountered when trying to compile NDB
+ API applications on a number of platforms, including 64-bit
+ Linux. As a result, <literal>libmysys</literal>,
+ <literal>libmystrings</literal>, and <literal>libdbug</literal>
+ have been changed from normal libraries to <quote>noinst</quote>
+ <command>libtool</command> helper libraries. They are no longer
+ installed as separate libraries; instead, all necessary symbols
+ from these are added directly to
+ <literal>libndbclient</literal>. This means that NDB API
+ programs now need to be linked only using
+ <option>-lndbclient</option>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="InnoDB"/>
+ <manual type="FLUSH TABLES"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36197"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.15"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When flushing tables, there was a slight chance that the flush
+ occurred between the processing of one table map event and the
+ next. Since the tables were opened one by one, subsequent
+ locking of tables would cause the slave to crash. This problem
+ was observed when replicating <literal>NDBCLUSTER</literal> or
+ <literal>InnoDB</literal> tables, when executing multi-table
+ updates, and when a trigger or a stored routine performed an
+ (additional) insert on a table so that two tables were
+ effectively being inserted into in the same statement.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="CREATE PROCEDURE"/>
+ <manual type="CREATE FUNCTION"/>
+ <manual type="comments"/>
+ <manual type="binary log"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36570"/>
+ <seealsobug bugid="32575"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.64"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">CREATE PROCEDURE</literal> and
+ <literal role="stmt">CREATE FUNCTION</literal> statements
+ containing extended comments were not written to the binary log
+ correctly, causing parse errors on the slave.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="CREATE VIEW"/>
+ <manual type="comments"/>
+ <manual type="binary log"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32575"/>
+ <seealsobug bugid="36570"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.62"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">CREATE VIEW</literal> statements containing
+ extended comments were not written to the binary log correctly,
+ causing parse errors on the slave. Now, all comments are
+ stripped from such statements before being written to the binary
+ log.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <manual type="ndb_apply_status"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36123"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.14"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Performing <literal>SELECT ... FROM
+ mysql.ndb_apply_status</literal> before the
+ <command>mysqld</command> process had connected to the cluster
+ failed, and caused this table never to be created.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_extra_logging"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36547"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.14"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>SET GLOBAL ndb_extra_logging</literal> caused
+ <command>mysqld</command> to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <highlight type="packaging"/>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36193"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message ver="5.1.24">
+
+ <para>
+ Beginning with this release, standard MySQL 5.1 binaries are no
+ longer built with support for the <literal>NDBCLUSTER</literal>
+ storage engine, and the <literal>NDBCLUSTER</literal> code
+ included in 5.1 mainline sources is no longer guaranteed to be
+ maintained or supported. Those using MySQL Cluster in MySQL
+ 5.1.23 and earlier MySQL 5.1 mainline releases should upgrade to
+ MySQL Cluster NDB 6.2.15 or a later MySQL Cluster NDB 6.2 or 6.3
+ release.
+ </para>
+
+ </message>
+
+ <message ver="6.0.5">
+
+ <para>
+ Beginning with this release, standard MySQL 6.0 binaries are no
+ longer built with support for the <literal>NDBCLUSTER</literal>
+ storage engine, and the <literal>NDBCLUSTER</literal> code
+ included in 6.0 mainline sources is no longer guaranteed to be
+ maintained or supported. Those using MySQL Cluster in MySQL
+ 6.0.4 and earlier MySQL 6.0 mainline releases should upgrade to
+ MySQL Cluster NDB 6.2.15 or a later MySQL Cluster NDB 6.2 or 6.3
+ release.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <highlight type="importantchange"/>
+ <highlight type="securityenhancement"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34593"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Windows Vista and Windows Server 2008, a user without
+ administrative privileges does not have write permissions to the
+ <filename>Program Files</filename> directory where MySQL and the
+ associated data files are normally installed. Using data files
+ located in the standard <filename>Program Files</filename>
+ installation directory could therefore cause MySQL to fail, or
+ lead to potential security issues in an installed instance.
+ </para>
+
+ <para>
+ To address the problem, on Windows XP, Windows Vista and Windows
+ Server 2008, the datafiles and data file configuration are now
+ set to the Microsoft recommended <filename>AppData</filename>
+ folder. The <filename>AppData</filename> folder is typically
+ located within the user's home directory.
+ </para>
+
+ <important>
+ <para>
+ When upgrading an existing 5.1.23 or 6.0.4 installation of
+ MySQL you must take a backup of your data and configuration
+ file (<filename>my.ini</filename> before installing the new
+ version. To migrate your data, either extract the data and
+ re-import (using <command>mysqldump</command>, then upgrade
+ and re-import using <command>mysql</command>), or back up your
+ data, upgrade to the new version, and copy your existing data
+ files from your old <filename>datadir</filename> directory to
+ the new directory located within <filename>AppData</filename>.
+ </para>
+ <para>
+ Failure to back up your data and follow these procedures may
+ lead to data loss.
+ </para>
+ </important>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="error 1427"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.14"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>NDB</literal> error 1427 (<errortext>Api node died,
+ when SUB_START_REQ reached node</errortext>) was incorrectly
+ classified as a schema error rather than a temporary error.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="QMGR"/>
+ <manual type="SUMA"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.14"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If an API node disconnected and then reconnected during Start
+ Phase 8, then the connection could be <quote>blocked</quote>
+ — that is, the <literal>QMGR</literal> kernel block failed
+ to detect that the API node was in fact connected to the
+ cluster, causing issues with the <literal>NDB</literal>
+ Subscription Manager (<literal>SUMA</literal>).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="NF_COMPLETEREP"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32645"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.14"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Notification of a cascading master node failures could sometimes
+ not be transmitted correctly (that is, transmission of the
+ <literal>NF_COMPLETEREP</literal> signal could fail), leading to
+ transactions hanging and timing out (<literal>NDB</literal>
+ error 4012), scans hanging, and failure of the management server
+ process.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35908"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some ordered index scans could return tuples out of order.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="NdbScanFilter::getNdbOperation()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35854"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>NdbScanFilter::getNdbOperation()</literal>, which was
+ inadvertently removed in MySQL Cluster NDB 6.3.11, has been
+ restored.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35853"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.15-ndb-6.1.13"/>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.15"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <filename>NdbApi.hpp</filename> depended on
+ <filename>ndb_global.h</filename>, which was not actually
+ installed, causing the compilation of programs that used
+ <filename>NdbApi.hpp</filename> to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35797"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Node or system restarts could fail due an unitialized variable
+ in the <literal>DTUP</literal> kernel block. This issue was
+ found in MySQL Cluster NDB 6.3.11.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="CREATE TABLE"/>
+ <manual type="SELECT"/>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35762"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The failure of a <literal>CREATE TABLE ... ENGINE=InnoDB ...
+ SELECT</literal> statement caused the slave to lose data.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb-cluster-connection-pool"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35573"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It was not possible to determine the value used for the
+ <option>--ndb-cluster-connection-pool</option> option in the
+ <command>mysql</command> client. Now this value is reported as a
+ system status variable.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="views"/>
+ <manual type="DUAL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35193"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When a view containing a reference to <literal>DUAL</literal>
+ was created, the reference was removed when the definition was
+ stored, causing some queries against the view to fail with
+ invalid SQL syntax errors.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35108"/>
+ <seealsobug bugid="35406"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>SELECT ... FROM
+ INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS</literal> caused the
+ server to crash if the table referenced by a foreign key had
+ been dropped. This issue was observed on Windows platforms only.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="AUTO_INCREMENT"/>
+ <manual type="foreign keys"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34920"/>
+ <regressionof bugid="23313"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Creating a foreign key on an <literal>InnoDB</literal> table
+ that was created with an explicit
+ <literal>AUTO_INCREMENT</literal> value caused that value to be
+ reset to 1.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <highlight type="importantchange"/>
+ <manual type="SIGPIPE"/>
+ <manual type="mysqld_safe"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33984"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqld_safe</command> now traps Signal 13
+ (<literal>SIGPIPE</literal>) so that this signal no longer kills
+ the MySQL server process.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="stored routines"/>
+ <manual type="DROP FUNCTION"/>
+ <manual type="DROP USER"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33464"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Dropping a function after dropping the function's creator
+ could cause the server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="REPLACE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="22045"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">REPLACE</literal> statements did not work
+ correctly with <literal>NDBCLUSTER</literal> tables when all
+ columns were not explicitly listed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CSV"/>
+ <manual type="UPDATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33067"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>CSV</literal> engine did not honor update requests
+ for <literal role="type">BLOB</literal> columns when the new
+ column value had the same length as the value to be updated.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql"/>
+ <manual type="clients"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33288"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <keycap>Control-R</keycap> in the <command>mysql</command>
+ client caused it to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ARCHIVE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26978"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Memory corruption, a crash of the MySQL server, or both, could
+ take place if a low-level I/O error occurred while an
+ <literal>ARCHIVE</literal> table was being opened.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="binary log"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35675"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Manually replacing a binary log file with a directory having the
+ same name caused an error that was not handled correctly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BENCHMARK()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="20752"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="func">BENCHMARK()</literal> function, invoked
+ with more than 2147483648 iterations (the size of a signed
+ 32-bit integer), terminated prematurely.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="PURGE BINARY LOGS"/>
+ </tags>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>PURGE BINARY LOGS TO</literal> and <literal>PURGE
+ BINARY LOGS BEFORE</literal> did not handle missing binary log
+ files correctly or in the same way. Now for both of these
+ statements, if any files listed in the
+ <filename>.index</filename> file are missing from the
+ filesystem, the statement fails with an error.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="AUTO_INCREMENT"/>
+ <manual type="triggers"/>
+ <manual type="stored routines"/>
+ <manual type="upgrades"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33029"/>
+ <seealsobug bugid="19630"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When a stored routine or trigger, running on a master that used
+ MySQL 5.0 or MySQL 5.1.11 or earlier, performed an insert on an
+ <literal>AUTO_INCREMENT</literal> column, the
+ <literal role="sysvar">insert_id</literal> value was not
+ replicated correctly to a slave running MySQL 5.1.12 or later
+ (including any MySQL 6.0 release).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="BLACKHOLE"/>
+ <manual type="INSERT_ID"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35178"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="sysvar">insert_id</literal> was not written to
+ the binary log for inserts into <literal>BLACKHOLE</literal>
+ tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="BLOB"/>
+ <manual type="TEXT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35593"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If an error occured while executing a statement involving a
+ <literal role="type">BLOB</literal> or
+ <literal role="type">TEXT</literal> column of an
+ <literal>NDB</literal> table, a memory leak could result.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_waiter"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35435"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <command>ndb_waiter</command> utility wrongly calculated
+ timeouts.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35413"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A <literal role="stmt">SELECT</literal> on a table with a
+ non-indexed, large <literal role="type">VARCHAR</literal> column
+ which resulted in condition pushdown on this column could cause
+ <command>mysqld</command> to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_restore"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35343"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>ndb_restore</command> incorrectly handled some
+ datatypes when applying log files from backups.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="errors"/>
+ <manual type="SQLSTATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35289"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In some cases, when too many clients tried to connect to the
+ server, the proper <literal>SQLSTATE</literal> code was not
+ returned.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35241"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In some circumstances, a stopped data node was handled
+ incorrectly, leading to redo log space being exhausted following
+ an initial restart of the node, or an initial or partial restart
+ of the cluster (the wrong CGI might be used in such cases). This
+ could happen, for example, when a node was stopped following the
+ creation of a new table, but before a new LCP could be executed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <manual type="binlog"/>
+ <manual type="ndb_log_updated_only"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35208"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In some cases, when updating only one or some columns in a
+ table, the complete row was written to the binary log instead of
+ only the updated column or columns, even when
+ <literal>ndb_log_updated_only</literal> was set to 1.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="LIKE"/>
+ <manual type="condition pushdown"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35185"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>SELECT ... LIKE ...</literal> queries yielded incorrect
+ results when used on <literal>NDB</literal> tables. As part of
+ this fix, condition pushdown of such queries has been disabled;
+ re-enabling it is expected to be done as part of a later,
+ permanent fix for this issue.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_mgm"/>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35169"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>ndb_mgmd</command> reported errors to
+ <literal>STDOUT</literal> rather than to
+ <literal>STDERR</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35137"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Nested multi-range reads failed when the second multi-range read
+ released the first read's unprocessed operations, sometimes
+ leading to an SQL node crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqldump"/>
+ <manual type="binary log"/>
+ <manual type="--master-data"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34909"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqldump</command> failed to return an error code when
+ using the <option>--master-data</option> option without binary
+ logging being enabled on the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="temporary tables"/>
+ <manual type="mysql database"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33275"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Executing a <literal role="stmt" condition="flush">FLUSH
+ PRIVILEGES</literal> statement after creating a temporary table
+ in the <literal>mysql</literal> database with the same name as
+ one of the MySQL system tables caused the server to crash.
+ <note>
+ <para>
+ While it is possible to shadow a system table in this way,
+ the temporary table exists only for the current user and
+ connection, and does not effect any user privileges.
+ </para>
+ </note>
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="FEDERATED"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34788"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A malformed URL used for a <literal>FEDERATED</literal>
+ table's <literal>CONNECTION</literal> option value in a
+ <literal role="stmt">CREATE TABLE</literal> statement was not
+ handled correctly and could crash the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34756"/>
+ <regressionof bugid="34033"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In some situations, a problem with synchronizing checkpoints
+ between nodes could cause a system restart or a node restart to
+ fail with <errortext>Error 630 during restore of TX</errortext>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="TRUNCATE"/>
+ <manual type="triggers"/>
+ <manual type="foreign keys"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34643"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Executing a <literal role="stmt">TRUNCATE</literal> statement on
+ a table having both a foreign key reference and a
+ <literal role="stmt">DELETE</literal> trigger crashed the
+ server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="indexes"/>
+ <manual type="DECIMAL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34515"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When a secondary index on a
+ <literal role="type">DECIMAL</literal> column was used to
+ retrieve data from an <literal>NDB</literal> table, no results
+ were returned even if the target table had a matched value in
+ the column that was defined with the secondary index.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="UPDATE"/>
+ <manual type="unique keys"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34208"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An <literal role="stmt">UPDATE</literal> on an
+ <literal>NDB</literal> table that set a new value for a unique
+ key column could cause subsequent queries to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34201"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If a data node in one node group was placed in the <quote>not
+ started</quote> state (using
+ <literal><replaceable>node_id</replaceable> RESTART
+ -n</literal>), it was not possible to stop a data node in a
+ different node group.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <manual type="FRAC_SECOND"/>
+ <manual type="MICROSECOND"/>
+ <manual type="TIMESTAMPADD()"/>
+ <manual type="TIMESTAMPDIFF()"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33834"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It was possible to use <literal>FRAC_SECOND</literal> as a
+ synonym for <literal>MICROSECOND</literal> with
+ <literal role="func">DATE_ADD()</literal>,
+ <literal role="func">DATE_SUB()</literal>, and
+ <literal role="func">INTERVAL</literal>; now, using
+ <literal>FRAC_SECOND</literal> with anything other than
+ <literal role="func">TIMESTAMPADD()</literal> or
+ <literal role="func">TIMESTAMPDIFF()</literal> produces a syntax
+ error.
+ </para>
+
+ <para>
+ It is now possible (and preferable) to use
+ <literal>MICROSECOND</literal> with
+ <literal role="func">TIMESTAMPADD()</literal> and
+ <literal role="func">TIMESTAMPDIFF()</literal>, and
+ <literal>FRAC_SECOND</literal> is now deprecated.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="WHERE"/>
+ <manual type="binary collations"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33833"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A query using <literal>WHERE
+ (column1='<replaceable>string1</replaceable>' AND
+ column2=<replaceable>constant1</replaceable>) OR
+ (column1='<replaceable>string2</replaceable>' AND
+ column2=<replaceable>constant2</replaceable>)</literal>, where
+ <literal>col1</literal> used a binary collation and
+ <replaceable>string1</replaceable> matched
+ <replaceable>string2</replaceable> except for case, failed to
+ match any records even when matches were found by a query using
+ the equivalent clause <literal>WHERE
+ column2=<replaceable>constant1</replaceable> OR
+ column2=<replaceable>constant2</replaceable></literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="libmysqld"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33796"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Reuse of prepared statements could cause a memory leak in the
+ embedded server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SELECT"/>
+ <manual type="ORDER BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33758"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In some cases a query that produced a result set when using
+ <literal>ORDER BY ASC</literal> did not return any results when
+ this was changed to <literal>ORDER BY DESC</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="clients"/>
+ <manual type="errors"/>
+ <manual type="system variables"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32757"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In some cases where setting a system variable failed, no error
+ was sent to the client, causing the client to hang.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="LIKE"/>
+ <manual type="character sets"/>
+ <manual type="eucjpms"/>
+ <manual type="ujis"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32510"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Queries using <literal>LIKE</literal> on tables having indexed
+ <literal role="type">CHAR</literal> columns using either of the
+ <literal>eucjpms</literal> or <literal>ujis</literal> character
+ sets did not return correct results.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <manual type="InnoDB"/>
+ <manual type="INFORMATION_SCHEMA"/>
+ <manual type="SHOW TABLE STATUS"/>
+ <manual type="DATA_FREE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32440"/>
+ <introducedby bugid="11379"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.13-ndb-6.3.11"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>InnoDB</literal> free space information is now shown in
+ the <literal>Data_free</literal> column of
+ <literal role="stmt">SHOW TABLE STATUS</literal> and in the
+ <literal>DATA_FREE</literal> column of the
+ <literal role="is">INFORMATION_SCHEMA.TABLES</literal> table.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ZEROFILL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31887"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Queries testing numeric constants containing leading zeroes
+ against <literal>ZEROFILL</literal> columns were not evaluated
+ correctly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="max_sort_length"/>
+ <manual type="sort_buffer_size"/>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31590"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server returned the error message <errortext>Out of memory;
+ restart server and try again</errortext> when the actual problem
+ was that the sort buffer was too small. Now an appropriate error
+ message is returned in such cases.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BLOB"/>
+ <manual type="TEXT"/>
+ <manual type="upgrades"/>
+ <manual type="indexes"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31331"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A table having an index that included a
+ <literal role="type">BLOB</literal> or
+ <literal role="type">TEXT</literal> column, and that was
+ originally created with a MySQL server using version 4.1 or
+ earlier, could not be opened by a 5.1 or later server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="stored functions"/>
+ <manual type="alias"/>
+ <manual type="subqueries"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30787"/>
+ <regressionof bugid="20777"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If an alias was used to refer to the value returned by a stored
+ function within a subselect, the outer select recognized the
+ alias but failed to retrieve the value assigned to it in the
+ subselect.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <manual type="CHAR"/>
+ <manual type="VARCHAR"/>
+ <manual type="TEXT"/>
+ <manual type="truncation"/>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30059"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.0.62"/>
+ <version ver="5.0.67"/>
+ <version ver="5.1.24"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.5"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message ver="5.0.60,5.1.24,6.0.5">
+
+ <para>
+ The server handled truncation of values having excess trailing
+ spaces into <literal role="type">CHAR</literal>,
+ <literal role="type">VARCHAR</literal>, and
+ <literal role="type">TEXT</literal> columns in different ways.
+ This behavior has now been made consistent for columns of all
+ three of these types, and now follows the existing behavior of
+ <literal role="type">VARCHAR</literal> columns in this regard;
+ that is, a <literal>Note</literal> is always issued whenever
+ such truncation occurs.
+ </para>
+
+ <para>
+ This change does not affect columns of these three types when
+ using a binary encoding; <literal role="type">BLOB</literal>
+ columns are also unaffected by the change, since they always use
+ a binary encoding.
+ </para>
+
+ </message>
+
+ <message ver="5.0.62,5.1.25,6.0.6">
+
+ <para>
+ The server no longer issues warnings for truncation of excess
+ spaces for values inserted into
+ <literal role="type">CHAR</literal> columns. This reverts a
+ change in the previous release that caused warnings to be
+ issued.
+ </para>
+
+ </message>
+
+ <message ver="5.0.67">
+
+ <para>
+ The server handled truncation of values having excess trailing
+ spaces into <literal role="type">VARCHAR</literal> and and
+ <literal role="type">TEXT</literal> columns in different ways.
+ This behavior has now been made consistent for columns of both
+ of these types, and now follows the existing behavior of
+ <literal role="type">VARCHAR</literal> columns in this regard;
+ that is, a <literal>Note</literal> is always issued whenever
+ such truncation occurs.
+ </para>
+
+ <para>
+ This change does not affect columns of these types when using a
+ binary encoding; <literal role="type">BLOB</literal> columns are
+ also unaffected by the change, since they always use a binary
+ encoding.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="myisamchk"/>
+ <manual type="character sets"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29182"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>myisamchk</command> always reported the character set
+ for a table as <literal>latin1_swedish_ci (8)</literal>
+ regardless of the table' actual character set.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="RBR"/>
+ <manual type="event scheduler"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29020"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The effects of scheduled events were not always correctly
+ reproduced on the slave when using row-based replication.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqldump"/>
+ <manual type="MERGE"/>
+ <manual type="UNION"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28248"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The SQL parser did not accept an empty
+ <literal>UNION=()</literal> clause. This meant that, when there
+ were no underlying tables specified for a
+ <literal>MERGE</literal> table, <literal role="stmt">SHOW CREATE
+ TABLE</literal> and <command>mysqldump</command> both output
+ statements that could not be executed.
+ </para>
+
+ <para>
+ Now it is possible to execute a <literal role="stmt">CREATE
+ TABLE</literal> or <literal role="stmt">ALTER TABLE</literal>
+ statement with an empty <literal>UNION=()</literal> clause.
+ However, <literal role="stmt">SHOW CREATE TABLE</literal> and
+ <command>mysqldump</command> do not output the
+ <literal>UNION=()</literal> clause if there are no underlying
+ tables specified for a <literal>MERGE</literal> table. This also
+ means it is now possible to remove the underlying tables for a
+ <literal>MERGE</literal> table using <literal>ALTER TABLE ...
+ UNION=()</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="index_merge"/>
+ <manual type="FLUSH"/>
+ <manual type="memory leaks"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27732"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It was possible to exhaust memory by repeatedly running
+ <literal>index_merge</literal> queries and never performing any
+ <literal role="stmt" condition="flush">FLUSH TABLES</literal>
+ statements.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="character sets"/>
+ <manual type="UTF8"/>
+ <manual type="SPACE()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27580"/>
+ <seealsobug bugid="23637"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When <literal>utf8</literal> was set as the connection character
+ set, using <literal role="func">SPACE()</literal> with a
+ non-Unicode column produced an error.
+ </para>
+
+ </message>
+
+ </logentry>
+
+<!-- # Following entry commented out until we
+ # verify if and where the fix went in...
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27004"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <filename>mgmapi.h</filename> contained constructs which only
+ worked in C++, but not in C.
+ </para>
+
+ </message>
+
+ </logentry>
+-->
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="START BACKUP"/>
+ <manual type="ndb_restore"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26498"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If a <literal>START BACKUP</literal> command was issued while
+ <command>ndb_restore</command> was running, the backup being
+ restored could be overwritten.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <highlight type="incompatiblechange"/>
+ <manual type="ALTER TABLE"/>
+ <manual type="ANALYZE PARTITION"/>
+ <manual type="CHECK PARTITION"/>
+ <manual type="OPTIMIZE PARTITION"/>
+ <manual type="REPAIR PARTITION"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="20129"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ <version ver="5.1.27"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message ver="5.1.24,6.0.5">
+
+ <para>
+ The following statements did not function correctly with
+ corrupted or crashed tables and have been removed:
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>ALTER TABLE ... ANALYZE PARTITION</literal>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>ALTER TABLE ... CHECK PARTITION</literal>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>ALTER TABLE ... OPTIMIZE PARTITION</literal>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>ALTER TABLE ... REPAIR PARTITION</literal>
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ <literal>ALTER TABLE ... REBUILD PARTITION</literal> is
+ unaffected by this change and continues to be available. This
+ statement and <literal>ALTER TABLE ... REORGANIZE
+ PARTITION</literal> may be used to analyze and optimize
+ partitioned tables, since these operations cause the partition
+ files to be rebuilt.
+ </para>
+
+ </message>
+
+ <message ver="5.1.27,6.0.6">
+
+ <para>
+ The statements <literal role="stmt">ANALYZE TABLE</literal>,
+ <literal role="stmt">CHECK TABLE</literal>,
+ <literal role="stmt">OPTIMIZE TABLE</literal>, and
+ <literal role="stmt">REPAIR TABLE</literal> are now supported
+ for partitioned tables.
+ </para>
+
+ </message>
+
+ <message ver="5.1.27">
+
+ <para>
+ This restores functionality missing since the removal of
+ <literal>ALTER TABLE ... ANALYZE PARTITION</literal>,
+ <literal>ALTER TABLE ... CHECK PARTITION</literal>,
+ <literal>ALTER TABLE ... OPTIMIZE PARTITION</literal>, and
+ <literal>ALTER TABLE ... REPAIR PARTITION</literal> in MySQL
+ 5.1.24.
+ </para>
+
+ </message>
+
+ <message ver="6.0.6">
+
+ <para>
+ This restores functionality missing since the removal of
+ <literal>ALTER TABLE ... ANALYZE PARTITION</literal>,
+ <literal>ALTER TABLE ... CHECK PARTITION</literal>,
+ <literal>ALTER TABLE ... OPTIMIZE PARTITION</literal>, and
+ <literal>ALTER TABLE ... REPAIR PARTITION</literal> in MySQL
+ 6.0.5.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="START SLAVE"/>
+ <manual type="MASTER_LOG_POS"/>
+ <manual type="circular replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="13861"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.50"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>START SLAVE UNTIL
+ MASTER_LOG_POS=<replaceable>position</replaceable></literal>
+ issued on a slave that was using
+ <option>--log-slave-updates</option> and that was involved in
+ circular replication would cause the slave to run and stop one
+ event later than that specified by the value of
+ <replaceable>position</replaceable>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="LIMIT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34768"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When using statement-based replication and a
+ <literal role="stmt">DELETE</literal>,
+ <literal role="stmt">UPDATE</literal>, or <literal>INSERT ...
+ SELECT</literal> statement using a <literal>LIMIT</literal>
+ clause is encountered, a warning that the statement is not safe
+ to replicate in statement mode is now issued; when using
+ <literal>MIXED</literal> mode, the statement is now replicated
+ using the row-based format.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="character sets"/>
+ <manual type="collations"/>
+ <manual type="identifiers"/>
+ <manual type="NAME_CONST()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34289"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The character sets and collations used for constant identifiers
+ in stored procedures were not replicated correctly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="START SLAVE"/>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="22989"/>
+ <seealsobug bugid="19328"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The inspecific error message <errortext>Wrong parameters to
+ function register_slave</errortext> resulted when
+ <literal role="stmt">START SLAVE</literal> failed to register on
+ the master due to excess length of any the slave server options
+ <option>--report-host</option>, <option>--report-user</option>,
+ or <option>--report-password</option>. An error message specific
+ to each of these options is now returned in such cases. The new
+ error messages are:
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <errortext>Failed to register slave: too long
+ 'report-host'</errortext>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <errortext>Failed to register slave: too long
+ 'report-user'</errortext>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <errortext>Failed to register slave; too long
+ 'report-password'</errortext>
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="PARTITION BY KEY"/>
+ <manual type="BIT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33379"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A table defined using <literal>PARTITION BY KEY</literal> and
+ having a <literal role="type">BIT</literal> column referenced in
+ the partitioning key did not behave correctly; some rows could
+ be inserted into the wrong partition, causing wrong results to
+ be returned from queries.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="DATA DIRECTORY"/>
+ <manual type="INDEX DIRECTORY"/>
+ <manual type="Windows"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30459"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using the DATA DIRECTORY and INDEX DIRECTORY options for
+ partitions with CREATE TABLE or ALTER TABLE statements appeared
+ to work on Windows, although they are not supported by MySQL on
+ Windows systems, and subsequent attempts to use the tables
+ referenced caused errors. Now these options are disabled on
+ Windows, and attempting to use them generates a warning.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="ALTER TABLE"/>
+ <manual type="ENGINE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31931"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Currently, all partitions of a partitioned table must use the
+ same storage engine. One may optinally specify the storage
+ engine on a per-partition basis; however, where this is the
+ done, the storage engine must be the same as used by the table
+ as a whole. <literal role="stmt">ALTER TABLE</literal> did not
+ enforce these rules correctly, the result being that incaccurate
+ error messages were shown when trying to use the statement to
+ change the storage engine used by an individual partition or
+ partitions.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="ALTER TABLE DROP PARTITION"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32943"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When <literal>ALTER TABLE DROP PARTITION</literal> was executed
+ on a table on which there was a trigger, the statement failed
+ with an error. This occurred even if the trigger did not
+ reference any tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="BIT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34358"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In some cases, matching rows from a partitioned
+ <literal>MyISAM</literal> using a
+ <literal role="type">BIT</literal> column as the primary key
+ were not found by queries.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="InnoDB"/>
+ <manual type="innodb_file_per_table"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33429"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Enabling <literal>innodb_file_per_table</literal> produced
+ problems with partitioning and tablespace operations on
+ partitioned <literal>InnoDB</literal> tables, in some cases
+ leading to corrupt partitions or causing the server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="MASTER_POS_WAIT()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26622"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>MASTER_POS_WAIT()</literal> did not return
+ <literal>NULL</literal> when the server was not a slave.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="CHANGE MASTER TO"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34686"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A <literal role="stmt">CHANGE MASTER TO</literal> statement with
+ no <literal>MASTER_HEARTBEAT_PERIOD</literal> option failed to
+ reset the heartbeat period to its default value.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31316"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Errors due to server ID conflicts were reported only in the
+ slave's error log; now these errors are also shown in the
+ <literal>Server_IO_State</literal> column in the output of
+ <literal role="stmt">SHOW SLAVE STATUS</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="mysqlbinlog"/>
+ <manual type="auto_increment_increment"/>
+ <manual type="auto_increment_offset"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34732"/>
+ <seealsobug bugid="31168"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqlbinlog</command> did not output the values of
+ <literal role="sysvar">auto_increment_increment</literal> and
+ <literal role="sysvar">auto_increment_offset</literal> when both
+ were equal to their default values (for both of these variables,
+ the default is 1). This meant that a binary log recorded by a
+ client using the defaults for both variables and then replayed
+ on another client using its own values for either or both of
+ these variables produced erroneous results.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="ROLLBACK"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33329"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An extraneous
+ <literal role="stmt" condition="commit">ROLLBACK</literal>
+ statement was written to the binary log by a connection that did
+ not use any transactional tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="system variables"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31168"/>
+ <seealsobug bugid="34732"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When running the server with
+ <option>--binlog-format=MIXED</option> or
+ <option>--binlog-format=STATEMENT</option>, a query that
+ referred to a system variable used the slave's value when
+ replayed on the slave. This meant that, if the value of a system
+ variable was inserted into a table, the slave differed from the
+ master. Now, statements that refer to a system variable are
+ marked as <quote>unsafe</quote>, which means that:
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ When the server is using
+ <option>--binlog-format=MIXED</option>, the row-based
+ format is used automatically to replicate these
+ statements.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ When the server is using
+ <option>--binlog-format=STATEMENT</option>, these
+ statements produce a warning.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="STOP SLAVE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31024"/>
+ <seealsobug bugid="30932"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">STOP SLAVE</literal> did not stop
+ connection attempts properly. If the IO slave thread was
+ attempting to connect, <literal role="stmt">STOP SLAVE</literal>
+ waited for the attempt to finish, sometimes for a long period of
+ time, rather than stopping the slave immediately.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="FreeBSD"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34292"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Compiling MySQL on FreeBSD would fail due to missing definitions
+ for certain network constants.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql_config"/>
+ <manual type="HP-UX"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29645"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <command>mysql_config</command> command would output
+ <literal>CFLAGS</literal> values that were incompatible with C++
+ for the HP-UX platform.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="SHOW CREATE TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33662"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The output from <literal role="stmt">SHOW CREATE TABLE</literal>
+ on a <literal>Falcon</literal> table would not include the
+ <literal>AUTO_INCREMENT</literal> value parameters.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <highlight type="partitioning"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33661"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An <literal role="stmt">INSERT</literal> into a
+ <literal>Falcon</literal> table with partitions and an
+ auto-increment column would fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33531"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <literal>falcon_debug_mask</literal> to enable debugging
+ messages could lead to some messages not being correctly flushed
+ to the log file.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="tablespace"/>
+ <manual type="DROP TABLESPACE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33212"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Dropping a tablespace for the <literal>Falcon</literal> storage
+ engine when the specified tablespace did not exist would
+ silently succeed, instead of generating a suitable error
+ message.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34086"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When inserting very large data sets into table using
+ <literal>INSERT INTO ... SELECT FROM</literal> on a
+ <literal>Falcon</literal> table when the value of
+ <option>falcon_page_cache_size</option> is higher than the
+ available memory. Instead of returning an error,
+ <command>mysqld</command> would crash in this instance.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33081"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <literal role="stmt">ALTER TABLE</literal> to convert a
+ <literal role="type">CHAR</literal> column using the
+ <literal>ucs2</literal> character set to
+ <literal role="type">VARBINARY</literal> when using a
+ <literal>Falcon</literal> table would cause a crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="NAME_CONST()"/>
+ <manual type="aggregate functions"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34749"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <literal>NAME_CONST()</literal> with a negative number and
+ an aggregate function caused MySQL to crash. This could also
+ have a negative impact on replication.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="TIMESTAMP"/>
+ <manual type="ON UPDATE CURRENT_TIMESTAMP"/>
+ <manual type="ON_UPDATE_NOW_FLAG"/>
+ <manual type="get_schema_column_record()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30081"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It was not possible for client applications to distinguish
+ between auto-set and auto-updated
+ <literal role="type">TIMESTAMP</literal> column values.
+ </para>
+
+ <para>
+ To rectify this problem, a new
+ <literal>ON_UPDATE_NOW_FLAG</literal> flag is set by
+ Field_timestamp constructors whenever a column should be set to
+ <literal>NOW</literal> on <literal role="stmt">UPDATE</literal>,
+ and the <literal>get_schema_column_record()</literal> function
+ now reports whether a timestamp column is set to
+ <literal>NOW</literal> on <literal role="stmt">UPDATE</literal>.
+ In addition, such columns now display <literal>on update
+ CURRENT_TIMESTAMP</literal> in the <literal>Extra</literal>
+ column in the output from <literal role="stmt">SHOW
+ COLUMNS</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="DECIMAL"/>
+ <manual type="indexes"/>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="25426"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Attempting to create an index with a prefix on a
+ <literal role="type">DECIMAL</literal> column appeared to
+ succeed with an inaccurate warning message. Now, this action
+ fails with the error <errortext>Incorrect prefix key; the used
+ key part isn't a string, the used length is longer than the key
+ part, or the storage engine doesn't support unique prefix
+ keys</errortext>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="strings"/>
+ <manual type="performance"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="14637"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The performance of internal functions that trim multiple spaces
+ from strings when comparing them has been improved.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <manual type="INFORMATION_SCHEMA.PARAMETERS"/>
+ <manual type="ROUTINE_TYPE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33106"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Added a <literal>ROUTINE_TYPE</literal> column to the
+ <literal role="is">INFORMATION_SCHEMA.PARAMETERS</literal>
+ table, to make it possible to distinguish like-named parameters
+ of stored routines and stored functions having the same names.
+ See <xref linkend="parameters-table"/>, for more information.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <highlight type="securityfix"/>
+ <manual type="DATA DIRECTORY"/>
+ <manual type="INDEX DIRECTORY"/>
+ <manual type="MyISAM"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32167"/>
+ <cve ref="CVE-2008-2079"/>
+ <seealsobug bugid="39277"/>
+ </bugs>
+
+ <versions>
+ <version ver="4.1.24"/>
+ <version ver="4.1.25"/>
+ <version ver="5.0.60"/>
+ <version ver="5.0.66sp1"/>
+ <version ver="5.0.67"/>
+ <version ver="5.0.70"/>
+ <version ver="5.1.24"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.5"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+<!--
+History of fixes for this bug:
+* Original fix applied to 4.1.24, 5.0.60, 5.1.24, 6.0.5
+* Secondary fix applied to 4.1.25, 5.0.70, 5.1.28, 6.0.6
+* Original fix applied to first Community release following 5.0.60
+ (i.e., 5.0.67)
+* Original + secondary fixes applied to 5.0.66sp1 Service Pack release
+-->
+
+ <message ver="4.1.24">
+
+ <para>
+ It was possible to circumvent privileges through the creation of
+ <literal>MyISAM</literal> tables employing the <literal>DATA
+ DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
+ options to overwrite existing table files in the MySQL data
+ directory. Use of the MySQL data directory in <literal>DATA
+ DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
+ pathname is now disallowed.
+ </para>
+
+ <note>
+ <para>
+ Additional fixes were made in MySQL 4.1.25.
+ </para>
+ </note>
+
+ </message>
+
+ <message ver="4.1.25">
+
+ <para>
+ Additional corrections were made for the symlink-related
+ privilege problem originally addressed in MySQL 4.1.24. The
+ original fix did not correctly handle the data directory
+ pathname if it contained symlinked directories in its path, and
+ the check was made only at table-creation time, not at
+ table-opening time later.
+ </para>
+
+ </message>
+
+ <message ver="5.0.60">
+
+ <para>
+ It was possible to circumvent privileges through the creation of
+ <literal>MyISAM</literal> tables employing the <literal>DATA
+ DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
+ options to overwrite existing table files in the MySQL data
+ directory. Use of the MySQL data directory in <literal>DATA
+ DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
+ pathname is now disallowed.
+ </para>
+
+ <note>
+ <para>
+ Additional fixes were made in MySQL 5.0.70.
+ </para>
+ </note>
+
+ </message>
+
+ <message ver="5.0.70">
+
+ <para>
+ Additional corrections were made for the symlink-related
+ privilege problem originally addressed in MySQL 5.0.60. The
+ original fix did not correctly handle the data directory
+ pathname if it contained symlinked directories in its path, and
+ the check was made only at table-creation time, not at
+ table-opening time later.
+ </para>
+
+ </message>
+
+ <message ver="5.0.67">
+
+ <para>
+ It was possible to circumvent privileges through the creation of
+ <literal>MyISAM</literal> tables employing the <literal>DATA
+ DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
+ options to overwrite existing table files in the MySQL data
+ directory. Use of the MySQL data directory in <literal>DATA
+ DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
+ pathname is now disallowed.
+ </para>
+
+<!--
+probably an "additional fixes" note should be added here when the
+next Community release after 5.0.67 is issued
+-->
+
+ </message>
+
+ <message ver="5.0.66sp1">
+
+ <para>
+ It was possible to circumvent privileges through the creation of
+ <literal>MyISAM</literal> tables employing the <literal>DATA
+ DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
+ options to overwrite existing table files in the MySQL data
+ directory. Use of the MySQL data directory in <literal>DATA
+ DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
+ pathname is now disallowed.
+ </para>
+
+ <para>
+ Additional corrections were made to handle the data directory
+ pathname if it contains symlinked directories in its path, and
+ to make the check both at table-creation time and at
+ table-opening time later.
+ </para>
+
+ </message>
+
+ <message ver="5.1.24">
+
+ <para>
+ It was possible to circumvent privileges through the creation of
+ <literal>MyISAM</literal> tables employing the <literal>DATA
+ DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
+ options to overwrite existing table files in the MySQL data
+ directory. Use of the MySQL data directory in <literal>DATA
+ DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal> is
+ now disallowed. This is now also true of these options when used
+ with partitioned tables and individual partitions of such
+ tables.
+ </para>
+
+ <note>
+ <para>
+ Additional fixes were made in MySQL 5.1.28.
+ </para>
+ </note>
+
+ </message>
+
+ <message ver="5.1.28">
+
+ <para>
+ Additional corrections were made for the symlink-related
+ privilege problem originally addressed in MySQL 5.1.24. The
+ original fix did not correctly handle the data directory
+ pathname if it contained symlinked directories in its path, and
+ the check was made only at table-creation time, not at
+ table-opening time later.
+ </para>
+
+ </message>
+
+ <message ver="6.0.5">
+
+ <para>
+ It was possible to circumvent privileges through the creation of
+ <literal>MyISAM</literal> tables employing the <literal>DATA
+ DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
+ options to overwrite existing table files in the MySQL data
+ directory. Use of the MySQL data directory in <literal>DATA
+ DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal> is
+ now disallowed. This is now also true of these options when used
+ with partitioned tables and individual partitions of such
+ tables.
+ </para>
+
+ <note>
+ <para>
+ Additional fixes were made in MySQL 6.0.6.
+ </para>
+ </note>
+
+ </message>
+
+ <message ver="6.0.6">
+
+ <para>
+ Additional corrections were made for the symlink-related
+ privilege problem originally addressed in MySQL 6.0.5. The
+ original fix did not correctly handle the data directory
+ pathname if it contained symlinked directories in its path, and
+ the check was made only at table-creation time, not at
+ table-opening time later.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="views"/>
+ <manual type="stored procedures"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34587"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Creating a view inside a stored procedure could lead to a crash
+ of the MySQL Server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="prepared statements"/>
+ <manual type="cursors"/>
+ <manual type="metadata"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32265"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Executing a prepared statement associated with a materialized
+ cursor sent to the client a metadata packet with incorrect table
+ and database names. The problem occurred because the server sent
+ the name of the temporary table used by the cursor instead of
+ the table name of the original table.
+ </para>
+
+ <para>
+ The same problem occured when selecting from a view, in which
+ case the name of the table name was sent, rather than the name
+ of the view.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="prepared statements"/>
+ <manual type="LIMIT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33851"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Passing anything other than a integer to a
+ <literal>LIMIT</literal> clause in a prepared statement would
+ fail. (This limitation was introduced to avoid replication
+ problems; for example, replicating the statement with a string
+ argument would cause a parse failure in the slave). Now,
+ arguments to the <literal>LIMIT</literal> clause are converted
+ to integer values, and these converted values are used when
+ logging the statement.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <manual type="triggers"/>
+ <manual type="AFTER UPDATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="23771"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An <literal>AFTER UPDATE</literal> trigger was not invoked when
+ the <literal role="stmt">UPDATE</literal> did not make any
+ changes to the table for which the trigger was defined. Now
+ <literal>AFTER UPDATE</literal> triggers behave the same in this
+ regard as do <literal>BEFORE UPDATE</literal> triggers, which
+ are invoked whether the <literal role="stmt">UPDATE</literal>
+ makes any changes in the table or not.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ALTER VIEW"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34337"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Executing an <literal role="stmt">ALTER VIEW</literal> statement
+ on a table crashed the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="views"/>
+ <manual type="GROUP BY"/>
+ <manual type="aggregate functions"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33049"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Under some circumstances a combination of aggregate functions
+ and <literal>GROUP BY</literal> in a
+ <literal role="stmt">SELECT</literal> query over a view could
+ lead to incorrect calculation of the result type of the
+ aggregate function. This in turn could lead to incorrect
+ results, or to crashes on debug builds of the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="views"/>
+ <manual type="charsets"/>
+ <manual type="collations"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32538"/>
+ <seealsobug bugid="21505"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A view created with a string literal for one of the columns
+ picked up the connection character set, but not the collation.
+ Comparison to that field therefore used the default collation
+ for that character set, causing an error if the connection
+ collation was not compatible with the default collation. The
+ problem was caused by text literals in a view being dumped with
+ a character set introducer even when this was not necessary,
+ sometimes leading to a loss of collation information. Now the
+ character set introducer is dumped only if it was included in
+ the original query.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ref_or_null"/>
+ <manual type="joins"/>
+ <manual type="NULL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34945"/>
+ <introducedby bugid="12144"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A query that performed a <literal>ref_or_null</literal> join
+ where the second table used a key having one or columns that
+ could be <literal>NULL</literal> and had a column value that was
+ <literal>NULL</literal> caused the server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ROW()"/>
+ <manual type="subqueries"/>
+ <manual type="aggregate functions"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34620"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some subqueries using an expression that included an aggregate
+ function could fail or in some cases lead to a crash of the
+ server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SET GLOBAL"/>
+ <manual type="innodb_commit_concurrency"/>
+ <manual type="innodb_autoextend_increment"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34223"/>
+ <regressionof bugid="31177"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Under some conditions, a <literal>SET GLOBAL
+ innodb_commit_concurrency</literal> or <literal>SET GLOBAL
+ innodb_autoextend_increment</literal> statement could fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="IN"/>
+ <manual type="CONCAT()"/>
+ <manual type="type conversion"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33764"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some queries using a combination of <literal>IN</literal>,
+ <literal role="func">CONCAT()</literal>, and an implicit type
+ conversion could return an incorrect result.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="DISTINCT"/>
+ <manual type="optimization"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32942"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal>DISTINCT</literal> queries, 4.0 and 4.1 stopped
+ reading joined tables as soon as the first matching row was
+ found. However, this optimization was lost in MySQL 5.0, which
+ instead read all matching rows. This fix for this regression may
+ result in a major improvement in performance for
+ <literal>DISTINCT</literal> queries in cases where many rows
+ match.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="views"/>
+ <manual type="stored routines"/>
+ <manual type="subselects"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33389"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Certain combinations of views, subselects with outer references
+ and stored routines or triggers could cause the server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="NULL"/>
+ <manual type="math"/>
+ <manual type="division by 0"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31236"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>-</literal>, <literal>*</literal>, and
+ <literal>/</literal> operators and the functions
+ <literal role="func">POW()</literal> and
+ <literal role="func">EXP()</literal> could misbehave when used
+ with floating-point numbers. Previously they might return
+ <literal>+INF</literal>, <literal>-INF</literal>, or
+ <literal>NaN</literal> in cases of numeric overflow (including
+ that caused by division by zero) or when invalid arguments were
+ used. Now <literal>NULL</literal> is returned in all such cases.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SET"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="15409"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A <literal>SET</literal> column whose definition specified 64
+ elements could not be updated using integer values.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="prepared statements"/>
+ <manual type="views"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32890"/>
+ <seealsobug bugid="34587"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Repeated creation and deletion of views within prepared
+ statements could eventually crash the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CREATE TABLE"/>
+ <manual type="SQL_MODE"/>
+ <manual type="NO_ZERO_DATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="18834"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">CREATE TABLE</literal> allowed 0 as the
+ default value for a <literal role="type">TIMESTAMP</literal>
+ column when the server was running in
+ <literal>NO_ZERO_DATE</literal> mode.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="Falcon"/>
+ <manual type="range scan"/>
+ <manual type="GROUP BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30573"/>
+ <fixes bugid="33257"/>
+ <fixes bugid="33555"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message ver="5.1.29">
+
+ <para>
+ Ordered range scans on partitioned tables were not always
+ handled correctly. In some cases this caused some rows to be
+ returned twice. The same issue also caused <literal>GROUP
+ BY</literal> query results to be aggregated incorrectly.
+ </para>
+
+ </message>
+
+ <message ver="6.0.5">
+
+ <para>
+ When the <literal>range</literal> access method was used on a
+ partitioned <literal>Falcon</literal> table, the entire index
+ was scanned. For partitioned tables using other storage engines,
+ a related issue caused an ordered range scan to return some rows
+ twice.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33688"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When using a transactional storage engine not using
+ statement-based logging, a duplicate key error on the master
+ caused replication to fail. This issue was first observed when
+ using the <literal>Falcon</literal> storage engine.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="compiling"/>
+ <manual type="FreeBSD"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34169"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.23-ndb-6.2.12"/>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When configured with <literal>NDB</literal> support, MySQL
+ failed to compile using <command>gcc</command> 4.3 on 64bit
+ FreeBSD systems.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="compiling"/>
+ <manual type="FreeBSD"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34046"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When configured with <literal>NDB</literal> support, MySQL
+ failed to compile on 64bit FreeBSD systems.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="MaxBufferedEpochs"/>
+ <manual type="binlog"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Added the <literal>MaxBufferedEpochs</literal> data node
+ configuration parameter, which controls the maximum number of
+ unprocessed epochs by which a subscribing node can lag.
+ Subscribers which exceed this number are disconnected and forced
+ to reconnect.
+ </para>
+
+ <para>
+ See <xref linkend="mysql-cluster-ndbd-definition"/>, for more
+ information.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <manual type="ndb-wait-connected"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34757"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <option>--ndb-wait-connected</option> option caused the
+ server to wait for a partial connection plus an additional 3
+ seconds for a complete connection to the cluster. This could
+ lead to issues with setting up the binary log.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="mysqlbinlog"/>
+ <manual type="Windows"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34355"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When the Windows version of <command>mysqlbinlog</command> read
+ 4.1 binlogs containing
+ <literal role="stmt" condition="load-data">LOAD DATA
+ INFILE</literal> statements, it output backslashes as path
+ separators, causing problems for client programs expecting
+ forward slashes. In such cases, it now converts
+ <literal>\\</literal> to <literal>/</literal> in directory
+ paths.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SET"/>
+ <manual type="DEFAULT"/>
+ <manual type="myisam_max_sort_file_size"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33382"/>
+ <seealsobug bugid="31177"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>SET GLOBAL myisam_max_sort_file_size=DEFAULT</literal>
+ set <literal>myisam_max_sort_file_size</literal> to an incorrect
+ value.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="GRANT"/>
+ <manual type="views"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33201"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Granting the <literal role="priv">UPDATE</literal> privilege on
+ one column of a view caused the server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="stack trace"/>
+ <manual type="debugging"/>
+ <manual type="gcc"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31891"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Formerly, when the MySQL server crashed, the generated stack
+ dump was numeric and required external tools to properly resolve
+ the names of functions. This is not very helpful to users having
+ a limited knowledge of debugging techniques. In addition, the
+ generated stack trace contained only the names of functions and
+ was formatted differently for each platform due to different
+ stack layouts.
+ </para>
+
+ <para>
+ Now it is possible to take advantage of newer versions of the
+ GNU C Library provide a set of functions to obtain and
+ manipulate stack traces from within the program. On systems that
+ use the ELF binary format, the stack trace contains important
+ information such as the shared object where the call was
+ generated, an offset into the function, and the actual return
+ address. Having the function name also makes possible the name
+ demangling of C++ functions.
+ </para>
+
+ <para>
+ The library generates meaningful stack traces on the following
+ platforms: i386, x86_64, PowerPC, IA64, Alpha, and S390. On
+ other platforms, a numeric stack trace is still produced, and
+ the use of the <command>resolve_stack_dump</command> utility is
+ still required.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CREATE SELECT"/>
+ <manual type="DEFAULT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="21380"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>CREATE ... SELECT</literal> did not always set
+ <literal>DEFAULT</literal> column values in the new table.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="routines"/>
+ <manual type="AUTOMCOMMIT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="12713"/>
+ <seealsobug bugid="34655"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If a <literal role="stmt">SELECT</literal> calls a stored
+ function in a transaction, and a statement within the function
+ fails, that statement should roll back. Furthermore, if
+ <literal role="stmt" condition="commit">ROLLBACK</literal> is
+ executed after that, the entire transaction should be rolled
+ back. Before this fix, the failed statement did not roll back
+ when it failed (even though it might ultimately get rolled back
+ by a <literal role="stmt" condition="commit">ROLLBACK</literal>
+ later that rolls back the entire transaction).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <manual type="Solaris"/>
+ <manual type="SPARC"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31646"/>
+ <seealsobug bugid="29549"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Replicating <literal>NDB</literal> tables with extra
+ <literal role="type">VARCHAR</literal> columns on the master
+ caused the slave to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="Config Wizard"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28628"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="5.0.51a"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When running the MySQL Instance Configuration Wizard, a race
+ condition could exist that would fail to connect to a newly
+ configured instance. This was because <command>mysqld</command>
+ had not completed the startup process before the next stage of
+ the installation process.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Maria"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34395"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-maria"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When creating tables not using the <literal>Maria</literal>
+ engine, it would be possible to create a table using the
+ <literal>TRANSACTIONAL</literal> option, even though this option
+ is not supported by non-<literal>Maria</literal> tables. A
+ warning will now be produced when using these options, but the
+ option will still be recorded within the options for the table
+ to allow for correct modification during
+ <literal role="stmt">ALTER TABLE</literal> operations.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="icc"/>
+ <manual type="IA64"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31239"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Numerous <literal>NDBCLUSTER</literal> test failures occurred in
+ builds compiled using <command>icc</command> on IA64 platforms.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="Solaris"/>
+ <manual type="x86"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="19911"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">CREATE TABLE</literal> and
+ <literal role="stmt">ALTER TABLE</literal> statements using
+ <literal>ENGINE=NDB</literal> or
+ <literal>ENGINE=NDBCLUSTER</literal> caused
+ <command>mysqld</command> to fail on Solaris 10 for x86
+ platforms.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="LCP"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34702"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.13"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A node failure during an initial node restart followed by
+ another node start could cause the master data node to fail,
+ because it incorrectly gave the node permission to start even if
+ the invalidated node's LCP was still running.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqld"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32350"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <command>mysqldump</command> utility did not print enough
+ version information about itself at the top of its output. The
+ output now shows the same information as
+ <command>mysqldump</command> invoked with the
+ <option>-V</option> option, namely the
+ <command>mysqldump</command> version number, the MySQL server
+ version, and the distribution.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="LCP"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34596"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.10"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Due to the reduction of the number of local checkpoints from 3
+ to 2 in MySQL Cluster NDB 6.3.8, a data node using ndbd from
+ MySQL Cluster NDB 6.3.8 or later started using a filesystem from
+ an earlier version could incorrectly invalidate local
+ checkpoints too early during the startup process, causing the
+ node to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="mysqlbinlog"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33247"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqlbinlog</command> failed to release all of its
+ memory after terminating abnormally.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33332"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The code implementing heartbeats did not check for possible
+ errors in some circumstances; this kept the dump thread hanging
+ while waiting for heartbeats loop even though the slave was no
+ longer connected.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="binlog"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34141"/>
+ <introducedby bugid="32407"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqlbinlog</command> from a 5.1 or later MySQL
+ distribution could not read binary logs generated by a 4.1
+ server when the logs contained
+ <literal role="stmt" condition="load-data">LOAD DATA
+ INFILE</literal> statements.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="SHOW SLAVE STATUS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34305"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.48"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">SHOW SLAVE STATUS</literal> failed when
+ slave I/O was about to terminate.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="RBR"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32971"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The error message generated due to lack of a default value for
+ an extra column was not sufficiently informative.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="backups"/>
+ <manual type="error messages"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="21052"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.48"/>
+ <version ver="5.1.21"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When a cluster backup was terminated using the <literal>ABORT
+ BACKUP</literal> command in the management client, a misleading
+ error message <errortext>Backup aborted by application:
+ Permanent error: Internal error</errortext> was returned. The
+ error message returned in such cases now reads <errortext>Backup
+ aborted by user request</errortext>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34445"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Cluster failures could sometimes occur when performing more than
+ three parallel takeovers during node restarts or system
+ restarts. This affected MySQL Cluster NDB
+ 6.3.<replaceable>x</replaceable> releases only.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="DataMemory"/>
+ <manual type="upgrades"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34378"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.12"/>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Upgrades of a cluster using while a
+ <literal>DataMemory</literal> setting in excess of 16 GB caused
+ data nodes to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="autocommit"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34275"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.12"/>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Performing many SQL statements on <literal>NDB</literal> tables
+ while in <literal role="sysvar">autocommit</literal> mode caused
+ a memory leak in <command>mysqld</command>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34260"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.12"/>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In certain rare circumstances, a race condition could occur
+ between an aborted insert and a delete leading a data node
+ crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="UPDATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34216"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.12"/>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Multi-table updates using ordered indexes during handling of
+ node failures could cause other data nodes to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34160"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.23-ndb-6.2.12"/>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The failure of a DDL statement could sometimes lead to node
+ failures when attempting to execute subsequent DDL statements.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="diskdata"/>
+ <highlight type="clusterreplication"/>
+ <manual type="UNIQUE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34118"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.12"/>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Statements violating unique keys on Disk Data tables (such as
+ attempting to insert <literal>NULL</literal> into a <literal>NOT
+ NULL</literal> column) could cause data nodes to fail. When the
+ statement was executed from the binlog, this could also result
+ in failure of the slave cluster.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="SELECT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34107"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.23-ndb-6.2.12"/>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Extremely long <literal role="stmt">SELECT</literal> statements
+ (where the text of the statement was in excess of 50000
+ characters) against <literal>NDB</literal> tables returned empty
+ results.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="diskdata"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33619"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.12"/>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Updating in-memory columns of one or more rows of Disk Data
+ table, followed by deletion of these rows and re-insertion of
+ them, caused data node failures.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33534"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.12"/>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Statements executing multiple inserts performed poorly on
+ <literal>NDB</literal> tables having
+ <literal>AUTO_INCREMENT</literal> columns.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_waiter"/>
+ <manual type="ndb_mgmd"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32025"/>
+ <seealsobug bugid="32023"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.12"/>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <command>ndb_waiter</command> utility polled
+ <command>ndb_mgmd</command> excessively when obtaining the
+ status of cluster data nodes.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31477"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.23-ndb-6.2.12"/>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Transaction atomicity was sometimes not preserved between reads
+ and inserts under high loads.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="backup"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30172"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.23-ndb-6.2.12"/>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Having tables with a great many columns could cause Cluster
+ backups to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.12"/>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Beginning with this version, MySQL Cluster NDB
+ 6.3.<replaceable>x</replaceable> releases once again include the
+ <literal>InnoDB</literal> storage engine. In order to enable
+ <literal>InnoDB</literal>, you must configure the build using
+ <option>--with-innodb</option>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <manual type="replicate-ignore-db"/>
+ <manual type="mysql.ndb_apply_status"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28170"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.12"/>
+ <version ver="5.1.23-ndb-6.3.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Setting <option>--replicate-ignore-db=mysql</option> caused the
+ <literal>mysql.ndb_apply_status</literal> table not to be
+ replicated, breaking Cluster Replication.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_mgmd"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32023"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The management server was slow to respond when no data nodes
+ were connected to the cluster. This was most noticeable when
+ running <literal>SHOW</literal> in the management client.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="DROP USER"/>
+ <manual type="CREATE USER"/>
+ <manual type="RENAME USER"/>
+ <manual type="binlog"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33862"/>
+ <seealsobug bugid="29749"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A <literal role="stmt">CREATE USER</literal>,
+ <literal role="stmt">DROP USER</literal>, or
+ <literal role="stmt">RENAME USER</literal> statement that fails
+ on the master, or that is a duplicate of any of these
+ statements, is no longer written to the binlog; previously,
+ either of these occurrences could cause the slave to fail.
+ </para>
+
+ <para></para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="--base64-output"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32407"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <option>--base64-output</option> option for
+ <command>mysqlbinlog</command> was not honored for all types of
+ events. This interfered in some cases with performing
+ point-in-time recovery.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <highlight type="importantchange"/>
+ <manual type="autocommit"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26395"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When the master crashed during an update on a transactional
+ table while in <literal role="sysvar">autocommit</literal> mode,
+ the slave failed. This fix causes every transaction (including
+ <literal role="sysvar">autocommit</literal> transactions) to be
+ recorded in the binlog as starting with a
+ <literal role="stmt" condition="commit">BEGIN</literal> and
+ ending with a <literal role="stmt">COMMIT</literal> or
+ <literal role="stmt" condition="commit">ROLLBACK</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="SHOW BINLOG EVENTS"/>
+ <manual type="max_allowed_packet"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33413"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">SHOW BINLOG EVENTS</literal> could fail
+ when the binlog contained one or more events whose size was
+ close to the value of
+ <literal role="sysvar">max_allowed_packet</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="server_id"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28908"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Setting <literal>server_id</literal> did not update its value
+ for the current session.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="mysqlbinlog"/>
+ <manual type="comments"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32205"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ SQL statements containing comments using <literal>--</literal>
+ syntax were not replayable by <command>mysqlbinlog</command>,
+ even though such statements replicated correctly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="DROP VIEW"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30998"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Issuing a <literal role="stmt">DROP VIEW</literal> statement
+ caused replication to fail if the view did not actually exist.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="importantnote"/>
+ <highlight type="replication"/>
+ <manual type="relay log"/>
+ <manual type="network connectivity"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26489"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Network timeouts between the master and the slave could result
+ in corruption of the relay log. This fix rectifies a
+ long-standing replication issue when using unreliable networks,
+ including replication over wide area networks such as the
+ Internet. If you experience reliability issues and see many
+ <errortext>You have an error in your SQL syntax</errortext>
+ errors on replication slaves, we strongly recommend that you
+ upgrade to a MySQL version which includes this fix.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="mysqlbinlog"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32580"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When a user variable was used inside an
+ <literal role="stmt">INSERT</literal> statement, the
+ corresponding binlog event was not written to the binlog
+ correctly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31581"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Replicating write, update, or delete events from a master
+ running MySQL 5.1.15 or earlier to a slave running 5.1.16 or
+ later caused the slave to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="RBR"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31609"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Introduced the <literal>slave_exec_mode</literal> system
+ variable to control whether idempotent or strict mode is used
+ for replication conflict resolution. Idempotent mode suppresses
+ duplicate-key, no-key-found, and some other errors, and is
+ needed for circular replication, multi-master replication, and
+ some other complex replication setups when using MySQL Cluster.
+ Strict mode is the default.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="RBR"/>
+ <manual type="binlog"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27779"/>
+ <fixes bugid="32434"/>
+ <introducedby bugid="22583"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some older servers wrote events to the binary log using
+ different numbering from what is currently used, even though the
+ file format number in the file is the same. Slaves running MySQL
+ 5.1.18 and later could not read these binary logs properly.
+ Binary logs from these older versions now are recognized and
+ event numbers are mapped to the current numbering so that they
+ can be interpreted properly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="RBR"/>
+ <manual type="upgrade"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31583"/>
+ <introducedby bugid="21842"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message ver="5.1.23-ndb-6.2.14,5.1.24-ndb-6.3.13">
+
+ <para>
+ When using row-based replication from a master running MySQL
+ 5.1.21 or earlier to a slave running 5.1.22 or later, updates of
+ integer columns failed on the slave with <errortext>Error in
+ Unknown event: row application failed</errortext>.
+ </para>
+
+ </message>
+
+ <message ver="5.1.24">
+
+ <para>
+ When using row-based replication from a master running MySQL
+ 5.1.21 or earlier to a slave running 5.1.22 or later, updates of
+ integer columns failed on the slave with <errortext>Error in
+ Unknown event: row application failed</errortext>.
+ </para>
+
+ </message>
+
+ <message ver="6.0.5">
+
+ <para>
+ When using row-based replication from a master running MySQL
+ 6.0.3 or earlier to a slave running 6.0.4 or later, updates of
+ integer columns failed on the slave with <errortext>Error in
+ Unknown event: row application failed</errortext>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="RBR"/>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32468"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When using row-based replication, deletes from a table with a
+ foreign key constraint failed on the slave.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="RBR"/>
+ <manual type="PRIMARY KEY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31552"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When using row-based replication, the slave stopped when
+ attempting to delete non-existent rows from a slave table
+ without a primary key. In addition, no error was reported when
+ this occurred.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="OPTIMIZE TABLE"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">OPTIMIZE TABLE</literal> can now be
+ interrupted. This can be done, for example, by killing the SQL
+ thread performing the <literal>OPTIMIZE</literal> operation.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Persistence of <literal>NDB</literal> tables can now be
+ controlled using the session variables
+ <literal>ndb_table_temporary</literal> and
+ <literal>ndb_table_no_logging</literal>.
+ <literal>ndb_table_no_logging</literal> causes
+ <literal>NDB</literal> tables not to be checkpointed to disk;
+ <literal>ndb_table_temporary</literal> does the same, and in
+ addition, no schema files are created.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Node recovery can now be done in parallel, rather than
+ sequentially, which can result in much faster recovery times.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <command>mysqld</command> option
+ <option>--ndb-batch-size</option> has been added. This allows
+ for controlling the size of batches used for running
+ transactions.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Now only 2 local checkpoints are stored, rather than 3 as in
+ previous MySQL Cluster versions. This lowers disk space
+ requirements and reduces the size and number of redo log files
+ needed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="TUP"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33739"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.11"/>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some tuple scans caused the wrong memory page to be accessed,
+ leading to invalid results. This issue could affect both
+ in-memory and Disk Data tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26913"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Under some circumstances, a recovering data node did not use its
+ own data, instead copying data from another node even when this
+ was not required. This in effect bypassed the optimized node
+ recovery protocol and caused recovery times to be unnecessarily
+ long.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28298"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.23-ndb-6.2.11"/>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It was possible in <filename>config.ini</filename> to define
+ cluster nodes having node IDs greater than the maximum allowed
+ value.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="backup"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28647"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.11"/>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The Cluster backup process could not detect when there was no
+ more disk space and instead continued to run until killed
+ manually. Now the backup fails with an appropriate error when
+ disk space is exhausted.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="diskdata"/>
+ <highlight type="importantchange"/>
+ <manual type="LOGFILE GROUP"/>
+ <manual type="DATAFILE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29186"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It is no longer possible on 32-bit systems to issue statements
+ appearing to create Disk Data log files or data files greater
+ than 4 GB in size. (Trying to create log files or data files
+ larger than 4 GB on 32-bit systems led to unrecoverable data
+ node failures; such statements now fail with
+ <literal>NDB</literal> error 1515.)
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="TRUNCATE"/>
+ <manual type="ON DUPLICATE KEY UPDATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29851"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.23-ndb-6.2.11"/>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Issuing an <literal>INSERT ... ON DUPLICATE KEY UPDATE</literal>
+ concurrently with or following a
+ <literal role="stmt">TRUNCATE</literal> statement on an
+ <literal>NDB</literal> table failed with <literal>NDB</literal>
+ error 4350 <errortext>Transaction already aborted</errortext>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <highlight type="importantchange"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30271"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.23-ndb-6.2.11"/>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Because <literal>NDB_LE_MemoryUsage.page_size_kb</literal> shows
+ memory page sizes in bytes rather than kilobytes, it has been
+ renamed to <literal>page_size_bytes</literal>. The name
+ <literal>page_size_kb</literal> is now deprecated and thus
+ subject to removal in a future release, although it currently
+ remains supported for reasons of backward compatibility. See
+ <xref linkend="ndb-logevent-type"/>, for more information about
+ <literal>NDB_LE_MemoryUsage</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="AUTO_INCREMENT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30417"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.11"/>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server failed to reject properly the creation of an
+ <literal>NDB</literal> table having an unindexed
+ <literal>AUTO_INCREMENT</literal> column.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="BIT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33750"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.23-ndb-6.2.11"/>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When reading a <literal>BIT(64)</literal> value using
+ <literal>NdbOperation:getValue()</literal>, 12 bytes were
+ written to the buffer rather than the expected 8 bytes.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33715"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A failure to initialize an internal variable led to sporadic
+ crashes during cluster testing.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="GCI"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33793"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.11"/>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A race condition could occur (very rarely) when the release of a
+ GCI was followed by a data node failure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="DataMemory"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33802"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">DROP TABLE</literal> did not free all data
+ memory. This bug was observed in MySQL Cluster NDB 6.3.7 only.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterapi"/>
+ <manual type="NdbTransaction::execute()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33895"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.11"/>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Transactions containing inserts or reads would hang during
+ <literal>NdbTransaction::execute()</literal> calls made from NDB
+ API applications built against a MySQL Cluster version that did
+ not support micro-GCPs accessing a later version that supported
+ micro-GCPs. This issue was observed while upgrading from MySQL
+ Cluster NDB 6.1.23 to MySQL Cluster NDB 6.2.10 when the API
+ application built against the earlier version attempted to
+ access a data node already running the later version, even after
+ disabling micro-GCPs by setting
+ <literal>TimeBetweenEpochs</literal> equal to 0.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34005"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.23-ndb-6.2.11"/>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A periodic failure to flush the send buffer by the
+ <literal>NDB</literal> TCP transporter could cause a unnecessary
+ delay of 10 ms between operations.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <manual type="binlog"/>
+ <manual type="DDL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34006"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Consecutive DDL statements involving tables
+ (<literal role="stmt">CREATE TABLE</literal>,
+ <literal role="stmt">ALTER TABLE</literal>, and
+ <literal role="stmt">DROP TABLE</literal>) could be executed so
+ quickly that previous DDL statements upon which they depended
+ were not yet written in the binary log.
+ </para>
+
+ <para>
+ For example, if <literal>DROP TABLE foo</literal> was issued
+ immediately following <literal>CREATE TABLE foo</literal>, the
+ <literal>DROP</literal> statement could fail because the
+ <literal>CREATE</literal> had not yet been recorded.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="disk data"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34033"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.11"/>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ High numbers of insert operations, delete operations, or both
+ could cause <literal>NDB</literal> error 899 (<errortext>Rowid
+ already allocated</errortext>) to occur unnecessarily.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_mgm"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30366"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The cluster management client could not connect, and would hang
+ instead. This issue affected Mac OS X 64-bit only.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="securityfix"/>
+ <highlight type="replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31611"/>
+ <cve ref="CVE-2007-6313"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It was possible for any connected user to issue a
+ <literal role="stmt">BINLOG</literal> statement, which could be
+ used to escalate privileges.
+ </para>
+
+ <para>
+ Use of the <literal role="stmt">BINLOG</literal> statement now
+ requires the <literal role="priv">SUPER</literal> privilege.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MyISAM"/>
+ <manual type="DELETE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28837"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When doing a <literal role="stmt">DELETE</literal> on a table
+ that involved a <literal>JOIN</literal> with
+ <literal>MyISAM</literal> or <literal>MERGE</literal> tables and
+ the <literal>JOIN</literal> referred to the same table, the
+ operation could fail reporting <literal>ERROR 1030 (HY000): Got
+ error 134 from storage engine</literal>. This was because scans
+ on the table contents would change because of rows that had
+ already been deleted.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BLOB"/>
+ <manual type="GEOMETRY"/>
+ <manual type="UNION"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31158"/>
+ </bugs>
+
+ <versions>
+ <version ver="4.1.24"/>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Data in <literal role="type">BLOB</literal> or
+ <literal>GEOMETRY</literal> columns could be cropped when
+ performing a <literal>UNION</literal> query.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="GEOMETRY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30284"/>
+ </bugs>
+
+ <versions>
+ <version ver="4.1.24"/>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Tables with a <literal>GEOMETRY</literal> column could be marked
+ as corrupt if you added a non-<literal>SPATIAL</literal> index
+ on a <literal>GEOMETRY</literal> column.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subquery"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31048"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Many nested subqueries in a single query could led to excessive
+ memory consumption and possibly a crash of the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="server variables"/>
+ <manual type="Linux"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31177"/>
+ <seealsobug bugid="6958"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Server variables could not be set to their current values on
+ Linux platforms.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="api"/>
+ <manual type="Windows"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31868"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When the language option was not set correctly, API programs
+ calling <literal role="cfunc">mysql_server_init()</literal>
+ crashed. This issue was observed only on Windows platforms.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CASE"/>
+ <manual type="AND"/>
+ <manual type="OR"/>
+ <manual type="SEL_ARG"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32403"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Repeated execution of a query containing a
+ <literal>CASE</literal> expression and numerous
+ <literal>AND</literal> and <literal>OR</literal> relations could
+ crash the server. The root cause of the issue was determined to
+ be that the internal <literal>SEL_ARG</literal> structure was
+ not properly initialized when created.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="DDL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32158"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An error in the internal function
+ <function>mysql_unpack_partition()</function> led to a fatal
+ error in subsequent calls to
+ <function>open_table_from_share()</function>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="EXPLAIN"/>
+ <manual type="Range checked for each record"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32241"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Memory corruption could occur due to large index map in
+ <literal>Range checked for each record</literal> status reported
+ by <literal>EXPLAIN SELECT</literal>. 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.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="NULL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32335"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Comparison of a <literal>BIGINT NOT NULL</literal> column with a
+ constant arithmetic expression that evaluated to NULL mistakenly
+ caused the error <errortext>Column '...' cannot be
+ null</errortext> (error 1048).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="FEDERATED"/>
+ <manual type="VIEW"/>
+ <manual type="ORDER BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32374"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An <literal>ORDER BY</literal> query on a view created using a
+ <literal>FEDERATED</literal> table as a base table caused the
+ server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subquery"/>
+ <manual type="WHERE"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32400"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Referencing within a subquery an alias used in the
+ <literal role="stmt">SELECT</literal> list of the outer query
+ was incorrectly permitted.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="GROUP BY"/>
+ <manual type="WITH ROLLUP"/>
+ <manual type="user variable"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32482"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A query of the form <literal>SELECT
+ @<replaceable>user_variable</replaceable> :=
+ <replaceable>constant</replaceable> AS
+ <replaceable>alias</replaceable> FROM
+ <replaceable>table</replaceable> GROUP BY
+ <replaceable>alias</replaceable> WITH ROLLUP</literal> crashed
+ the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SELECT INTO OUTFILE"/>
+ <manual type="LOAD DATA INFILE"/>
+ <manual type="character sets"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32533"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <literal>SELECT INTO OUTFILE</literal> with 8-bit
+ <literal>ENCLOSED BY</literal> characters led to corrupted data
+ when the data was reloaded using LOAD DATA INFILE. This was
+ because <literal>SELECT INTO OUTFILE</literal> failed to escape
+ the 8-bit characters.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BIT"/>
+ <manual type="GROUP BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32556"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A <literal>SELECT ... GROUP BY
+ <replaceable>bit_column</replaceable></literal> query failed
+ with an assertion if the length of the
+ <literal role="type">BIT</literal> column used for the
+ <literal>GROUP BY</literal> was not an integer multiple of 8.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="IS NULL"/>
+ <manual type="NOT NULL"/>
+ <manual type="subquery"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32694"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A subquery using an <literal>IS NULL</literal> check of a column
+ defined as <literal>NOT NULL</literal> in a table used in the
+ <literal>FROM</literal> clause of the outer query produced an
+ invalid result.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="securityenhancement"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32707"/>
+ </bugs>
+
+ <versions>
+ <version ver="4.1.24"/>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ 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.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ORDER BY"/>
+ <manual type="IS NULL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32815"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An <literal>ORDER BY</literal> query using <literal>IS
+ NULL</literal> in the <literal>WHERE</literal> clause did not
+ return correct results.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MERGE"/>
+ <manual type="FLUSH"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30273"/>
+ <introducedby bugid="26379"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Flushing a merge table between the time it was opened and its
+ child table were actually attached caused the server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="CSV"/>
+ <manual type="NULL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32050"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It is no longer possible to create <literal>CSV</literal> tables
+ with <literal>NULL</literal> columns. However, for backwards
+ compatibility, you can continue to use such tables that were
+ created in previous MySQL releases.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_restore"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>ndb_restore</command> now supports basic
+ <firstterm>attribute promotion</firstterm>; that is, data from a
+ column of a given type can be restored to a column using a
+ <quote>larger</quote> type. For example, Cluster backup data
+ taken from a <literal role="type">SMALLINT</literal> column can
+ be restored to a <literal role="type">MEDIUMINT</literal>,
+ <literal role="type">INT</literal>, or
+ <literal role="type">BIGINT</literal> column.
+ </para>
+
+ <para>
+ For more information, see
+ <xref linkend="mysql-cluster-restore"/>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ARCHIVE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31833"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <literal>ORDER BY</literal> led to the wrong result when
+ using the <literal>ARCHIVE</literal> on a table with a
+ <literal role="type">BLOB</literal> when the table cache was
+ full. The table could also be reported as crashed after the
+ query had completed, even though the table data was intact.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="transaction_allow_batching"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It is now possible to cause statements occurring within the same
+ transaction to be run as a batch by setting the session variable
+ <literal>transaction_allow_batching</literal> to
+ <literal>1</literal> or <literal>ON</literal>.
+ </para>
+
+ <note>
+ <para>
+ To use this feature, autocommit must be disabled.
+ </para>
+ </note>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <manual type="ndb_binlog_index"/>
+ <manual type="ndb-log-orig"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.22-ndb-6.3.2"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Multi-way replication failover and recovery for
+ <literal>NDB</literal> is facilitated with the introduction of
+ the <option>--ndb-log-orig</option> option. When
+ <command>mysqld</command> is started with this option, the
+ originating server ID and epoch of each binlog event is recorded
+ in the <literal>mysql.ndb_binlog_index</literal> table, which
+ now contains two additional columns
+ <literal>orig_server_id</literal> and
+ <literal>orig_epoch</literal> for storing this information. In
+ such cases, a single epoch on a slave may be represented by
+ multiple rows in the slave's
+ <literal>ndb_binlog_index</literal> table, one for each epoch as
+ it originated from a master.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="OPTIMIZE TABLE"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">OPTIMIZE TABLE</literal> is now supported
+ for <literal>NDB</literal> tables, subject to the following
+ limitations:
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Only in-memory tables are supported.
+ <literal>OPTIMIZE</literal> still has no effect on Disk
+ Data tables.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Only variable-length columns are supported. However, you
+ can force columns defined using fixed-length data types to
+ be dynamic using the <literal>ROW_FORMAT</literal> or
+ <literal>COLUMN_FORMAT</literal> option with a
+ <literal role="stmt">CREATE TABLE</literal> or
+ <literal role="stmt">ALTER TABLE</literal> statement.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ Memory reclaimed from an <literal>NDB</literal> table using
+ <literal>OPTIMIZE</literal> is generally available to the
+ cluster, and not confined to the table from which it was
+ recovered, unlike the case with memory freed using
+ <literal role="stmt">DELETE</literal>.
+ </para>
+
+ <para>
+ The performance of <literal>OPTIMIZE</literal> on
+ <literal>NDB</literal> tables can be regulated by adjusting the
+ value of the <literal>ndb_optimization_delay</literal> system
+ variable.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_mgm"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33237"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.23-ndb-6.2.10"/>
+ <version ver="5.1.23-ndb-6.3.7"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When all data and SQL nodes in the cluster were shut down
+ abnormally (that is, other than by using <literal>STOP</literal>
+ in the cluster management client), <command>ndb_mgm</command>
+ used excessive amounts of CPU.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <highlight type="partitioning"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33061"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.10"/>
+ <version ver="5.1.23-ndb-6.3.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When partition pruning on an <literal>NDB</literal> table
+ resulted in an ordered index scan spanning only one partition,
+ any descending flag for the scan was wrongly discarded, causing
+ <literal>ORDER BY DESC</literal> to be treated as <literal>ORDER
+ BY ASC</literal>, <literal>MAX()</literal> to be handled
+ incorrectly, and similar problems.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <manual type="RBR"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33375"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A replication slave could return <quote>garbage</quote> data
+ that was not in recognizable row format due to a problem with
+ the internal <literal>all_set()</literal> method.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <manual type="ndb_restore"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33406"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.11"/>
+ <version ver="5.1.23-ndb-6.3.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>ndb_restore -e</command> restored excessively large
+ values to the <literal>ndb_apply_status</literal> table's
+ <literal>epoch</literal> column when restoring to a MySQL
+ Cluster version supporting Micro-GCPs from an older version that
+ did not support these.
+ </para>
+
+ <para>
+ A workaround when restoring to MySQL Cluster releases supporting
+ micro-GCPs previous to MySQL Cluster NDB 6.3.8 is to perform a
+ 32-bit shift on the <literal>epoch</literal> column values to
+ reduce them to their proper size.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <manual type="mysql.ndb_replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33159"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Creating the <literal>mysql.ndb_replication</literal> table with
+ the wrong number of columns for the primary key caused
+ <command>mysqld</command> to crash. Now a <literal>CREATE TABLE
+ [mysql.]ndb_replication</literal> statement that is invalid for
+ this reason fails with the error <errortext>Bad schema for
+ mysql.ndb_replication table. Message: Wrong number of primary
+ keys, expected <replaceable>number</replaceable></errortext>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="Blob"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32062"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Inserting, updating and deleting a large number of
+ <literal role="type">BLOB</literal> records in a
+ <literal>Falcon</literal> table would take significant amount of
+ time and may prevent shutdown.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28541"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using a temporary table within <literal>Falcon</literal> that is
+ created in a directory where the path contains a mixture of
+ upper and lower letters would fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="clusterreplication"/>
+ <manual type="NdbBlob"/>
+ <manual type="CREATE INDEX"/>
+ <manual type="ADD INDEX"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33142"/>
+ <seealsobug bugid="18106"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Memory was mistakenly freed for <literal>NdbBlob</literal>
+ objects when adding an index while replicating the cluster,
+ which could cause <command>mysqld</command> to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="GCI"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32922"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.10"/>
+ <version ver="5.1.23-ndb-6.3.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When using micro-GCPs, if a node failed while preparing for a
+ global checkpoint, the master node would use the wrong GCI.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="SUMA"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32652"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ 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.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="PRIMARY KEY"/>
+ <manual type="VARCHAR"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31635"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Primary keys on variable-length columns (such as
+ <literal role="type">VARCHAR</literal>) did not work correctly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_mgmd"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29621"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Log event requests to <command>ndb_mgmd</command> could time
+ out, causing it to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ALTER TABLE"/>
+ <manual type="Table is full"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32670"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.10"/>
+ <version ver="5.1.23-ndb-6.3.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Under some conditions, performing an <literal role="stmt">ALTER
+ TABLE</literal> on an <literal>NDBCLUSTER</literal> table failed
+ with a <errortext>Table is full</errortext> error, even when
+ only 25% of <literal>DataMemory</literal> was in use and the
+ result should have been a table using less memory (for example,
+ changing a <literal>VARCHAR(100)</literal> column to
+ <literal>VARCHAR(80)</literal>).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29139"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The error message for <literal>NDB</literal> error code 275
+ (<errortext>Out of transaction records for complete
+ phase</errortext>) was missing.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28445"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ 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.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="binlog"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32275"/>
+ <fixes bugid="33763"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When a <command>mysqld</command> acting as a cluster SQL node
+ starts the <literal>NDBCLUSTER</literal> storage engine, there
+ is a delay during which some necessary data structures cannot be
+ initialized until after it has connected to the cluster, and all
+ MySQL Cluster tables should be opened as read-only. This worked
+ correctly when the <literal>NDB</literal> binlog thread was
+ running, but when it was not running, Cluster tables were not
+ opened as read-only even when the data structures had not yet
+ been set up.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="TC"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33168"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Incorrectly handled parameters could lead to a crash in the
+ Transaction Coordinator during a node failure, causing other
+ data nodes to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33206"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An improperly reset internal signal was observed as a hang when
+ using events in the <literal>NDB</literal> API but could result
+ in various errors.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="data types"/>
+ <manual type="cast"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30453"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When casting a string value to an integer, cases where the input
+ string contained a decimal point and was long enough to overrun
+ the <literal>unsigned long long</literal> type were not handled
+ correctly. The position of the decimal point was not taken into
+ account which resulted in miscalculated numbers and incorrect
+ truncation to appropriate SQL data type limits.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="NAME_CONST()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27545"/>
+ <fixes bugid="32559"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some queries using the
+ <literal role="func">NAME_CONST()</literal> function failed to
+ return either a result or an error to the client, causing it to
+ hang. This was due to the fact that there was no check to insure
+ that both arguments to this function were constant expressions.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="precision"/>
+ <manual type="FLOAT"/>
+ <manual type="CHAR"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26788"/>
+ <seealsobug bugid="12860"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqld</command> sometimes miscalculated the number of
+ digits required when storing a floating-point number in a
+ <literal role="type">CHAR</literal> column. This caused the
+ value to be truncated, or (when using a debug build) caused the
+ server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="arithmetic precision"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="24907"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If the expected precision of an arithmetic expression exceeded
+ the maximum precision supported by MySQL, the precision of the
+ result was reduced by an unpredictable or arbitrary amount,
+ rather than to the maximum precision. In some cases, exceeding
+ the maximum supported precision could also lead to a crash of
+ the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="KILL"/>
+ <manual type="Mac OS X"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="19723"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Issuing an SQL <literal role="stmt">KILL</literal> of the active
+ connection caused an error on Mac OS X.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="ORDER BY DESC"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31890"/>
+ <seealsobug bugid="31001"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>ORDER BY ... DESC</literal> did not always work
+ correctly when selecting from partitioned tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="AUTO_INCREMENT"/>
+ <manual type="InnoDB"/>
+ <manual type="ARCHIVE"/>
+ <manual type="SHOW CREATE TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32247"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">SHOW CREATE TABLE</literal> misreported the
+ value of <literal>AUTO_INCREMENT</literal> for partitioned
+ tables using either of the <literal>InnoDB</literal> or
+ <literal>ARCHIVE</literal> storage engines.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="SET"/>
+ <manual type="GROUP BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32772"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A query of the form <literal>SELECT
+ <replaceable>col1</replaceable> FROM
+ <replaceable>table</replaceable> GROUP BY (SELECT
+ <replaceable>col2</replaceable> FROM
+ <replaceable>table</replaceable> LIMIT 1);</literal> against a
+ partitioned <replaceable>table</replaceable> having a
+ <literal>SET</literal> column crashed the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="INFORMATION_SCHEMA"/>
+ <manual type="ALTER TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32178"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Selecting from
+ <literal role="is">INFORMATION_SCHEMA.PARTITIONS</literal> while
+ partition management statements (for example, <literal>ALTER
+ TABLE ... ADD PARTITION</literal>) were executing caused the
+ server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="LCP"/>
+ <manual type="backup"/>
+ <manual type="ndb_restore"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.3.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Compressed local checkpoints and backups are now supported,
+ resulting in a space savings of 50% or more over uncompressed
+ LCPs and backups. Cmpression of these can be enabled in the
+ <filename>config.ini</filename> file using the two new data node
+ configuration parameters <literal>CompressedLCP</literal> and
+ <literal>CompressedBackup</literal>, respectively.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="ALTER TABLE"/>
+ <manual type="COALESCE PARTITION"/>
+ <manual type="PARTITION BY HASH"/>
+ <manual type="PARTITION BY KEY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30822"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>ALTER TABLE ... COALESCE PARTITION</literal> on a table
+ partitioned by <literal>[LINEAR] HASH</literal> or
+ <literal>[LINEAR] KEY</literal> caused the server to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="MAXVALUE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29258"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ 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:
+<programlisting>
+CREATE TABLE t (c BIGINT UNSIGNED)
+ PARTITION BY RANGE(c) (
+ PARTITION p0 VALUES LESS THAN MAXVALUE
+ );
+</programlisting>
+ The largest possible value for a <literal>BIGINT
+ UNSIGNED</literal> column is 18446744073709551615, but the
+ statement <literal>INSERT INTO t VALUES
+ (18446744073709551615);</literal> would fail, even though the
+ same statement succeeded were <literal>t</literal> not a
+ partitioned table.
+ </para>
+
+ <para>
+ In other words, <literal>MAXVALUE</literal> was treated as being
+ equal to the greatest possible value, rather than as a least
+ upper bound.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="Falcon"/>
+ <manual type="LIKE"/>
+ <manual type="PARTITION BY KEY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30480"/>
+ <seealsobug bugid="29320"/>
+ <seealsobug bugid="29493"/>
+ <seealsobug bugid="30563"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message ver="5.1.23">
+
+ <para>
+ <literal>LIKE</literal> queries on tables partitioned by
+ <literal>KEY</literal> and using third-party storage engines
+ could return incomplete results.
+ </para>
+
+ </message>
+
+ <message ver="6.0.5">
+
+ <para>
+ <literal>LIKE</literal> queries on tables partitioned by
+ <literal>KEY</literal> could return incomplete results. The
+ problem was observed with the <literal>Falcon</literal> storage
+ engine, but could affect third-party storage engines as well.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="foreign keys"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32948"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It was possible to partition a table to which a foreign key
+ referred.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <highlight type="importantchange"/>
+ <manual type="AUTO_INCREMENT"/>
+ <manual type="ndb_autoincrement_prefetch_sz"/>
+ <manual type="INSERT IGNORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="25176"/>
+ <fixes bugid="31956"/>
+ <fixes bugid="32055"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>AUTO_INCREMENT</literal> columns had the following
+ problems when used in <literal>NDB</literal> tables:
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The <literal>AUTO_INCREMENT</literal> counter was not
+ updated correctly when such a column was updated.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>AUTO_INCREMENT</literal> values were not
+ prefetched beyond statement boundaries.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>AUTO_INCREMENT</literal> values were not handled
+ correctly with <literal>INSERT IGNORE</literal>
+ statements.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ After being set,
+ <literal>ndb_autoincrement_prefetch_sz</literal> showed a
+ value of 1, regardless of the value it had actually been
+ set to.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ As part of this fix, the behavior of
+ <literal>ndb_autoincrement_prefetch_sz</literal> 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
+ <literal>1</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Solaris"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31268"/>
+ <fixes bugid="33126"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Building a 64-bit binary with support for the
+ <literal>Falcon</literal> storage engine using
+ <command>gcc</command> on Solaris could fail. See
+ <xref linkend="installing-source"/>, for more information.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="Falcon"/>
+ <highlight type="incompatiblechange"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Because of a change in the format of the
+ <literal>Falcon</literal> pages stored within
+ <literal>Falcon</literal> database files,
+ <literal>Falcon</literal> databases created in MySQL 6.0.4 (or
+ later) are not compatible with previous releases, and existing
+ <literal>Falcon</literal> databases are incompatible with MySQL
+ 6.0.4 (and later versions. You should dump
+ <literal>Falcon</literal> databases using
+ <command>mysqldump</command> before upgrading, and then reload
+ them after the upgrade. For more information, see
+ <xref linkend="mysqldump"/>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28519"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Under heavy load when updating <literal>Falcon</literal> tables,
+ a race condition could occur that would ultimately result in a
+ crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <highlight type="replication"/>
+ <manual type="RBR"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31671"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Falcon</literal> tables would fail during replication
+ if ROW-based replication was specified.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32413"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Falcon</literal> options to set the limits of memory
+ usage would not be honored. This could lead to crashes and
+ assertions during normal usage, instead of generating a suitable
+ warning.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29870"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Running the <command>sqlbench</command> test suite against
+ <literal>Falcon</literal> would cause a crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32862"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <literal>Falcon</literal> when accessing multiple versions
+ of the same record, certain records could fail to be retrieved
+ from the record cache, causing an assertion failure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="LOAD DATA INFILE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29081"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When loading large data sets using
+ <literal role="stmt" condition="load-data">LOAD DATA
+ INFILE</literal> into a <literal>Falcon</literal> table, the
+ server could crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="ALTER TABLE"/>
+ <manual type="OPTIMIZE PARTITION"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30826"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Running <literal>ALTER TABLE ... OPTIMIZE PARTITION</literal> on
+ a <literal>Falcon</literal> table, a 'divide by zero' error
+ would be reported during a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27426"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Searching a <literal>Falcon</literal> table that uses
+ <literal role="type">DATETIME</literal> columns with an index
+ could return incorrect results.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29151"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Inserting information into the same table from multiple threads
+ could cause duplicate key errors. This was related to the
+ changes made to allow compatibility with the
+ <literal>InnoDB</literal> repeatable-read isolation level. The
+ option, <option>falcon_innodb_compatibility</option>, has been
+ renamed to <option>falcon_consistent_read</option>, but with the
+ opposite effect. The default is for this option to be on. When
+ set to off, the behavior of <literal>Falcon</literal> is similar
+ to that in <literal>InnoDB</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32829"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Converting a table from <literal>InnoDB</literal> to
+ <literal>Falcon</literal>, where the <literal>Falcon</literal>
+ table with the same name (but different case) would cause a
+ server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="DATETIME"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31490"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When inserting dates into a
+ <literal role="type">DATETIME</literal> column with a
+ <literal>Falcon</literal>, the values would automatically be
+ converted with values between 70 and 99 converted to 1970-1999,
+ and values from 00 to 69 converted to 2000 to 2069. These dates
+ are now correctly handled.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="22125"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Selecting information from a <literal>Falcon</literal> table
+ using a <literal role="type">DOUBLE</literal> column with an
+ index would produce incorrect results.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="22842"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <literal>CREATE UNIQUE INDEX</literal> on a
+ <literal>Falcon</literal> table where rows contain duplicate
+ values could result in pending transactions to the table being
+ deleted.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32833"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Creating an index on a <literal>Falcon</literal> table with a
+ column using UTF32 that has been converted to UTF8 would cause a
+ server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27424"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Mixing differently cased tables between
+ <literal>MyISAM</literal> and <literal>Falcon</literal> tables
+ would cause a crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27425"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Removing a partition on a <literal>Falcon</literal> table when
+ there are two tables with the same name, but different case,
+ would cause a crash during normal shutdown.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32301"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Falcon</literal> would incorrectly return the supported
+ repeatable-read level when queried by the Online Backup system,
+ preventing the ability to create a consistent snapshot backup.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="TABLESPACE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32621"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Repeatedly creating and dropping <literal>Falcon</literal>
+ tablespaces failed because the old tablespace was not dropped
+ before the new tablespace file was created.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32830"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <literal role="stmt">ALTER TABLE</literal> on a
+ <literal>Falcon</literal> table it would be possible to create
+ two tables with the same name but different case.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="DATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="22168"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Creating a <literal role="type">DATE</literal> outside the
+ normal range within a <literal>Falcon</literal> table would
+ result in a zero <literal role="type">DATE</literal> value being
+ returned, even though normally invalid values would be stored
+ correctly in other storage engines.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29823"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When accessing the statistics in
+ <literal>INFORMATION_SCHEMA.FALCON_DATABASE_IO</literal>, the
+ information related only to the <literal>Falcon</literal>
+ database, and not to user tablespaces. The output has been
+ updated to report on all tablespaces, and the
+ <literal>DATABASE</literal> column has been renamed to
+ <literal>TABLESPACE</literal> to reflect the fact that these
+ statistics are now reported by tablespace, not by database.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31311"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>TABLESPACE</literal> names within
+ <literal>Falcon</literal> did not support characters outside the
+ alpha-numeric ASCII character set.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32554"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Falcon</literal> used a fixed index key size which was
+ too small to cope with some <literal>Falcon</literal> page
+ sizes, leading to a crash. <literal>Falcon</literal> now
+ supports variable-length index keys according to the supported
+ page sizes. See
+ <literal><link linkend="option_mysqld_falcon_page_size">falcon_page_size</link></literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="TRUNCATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="22173"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <literal role="stmt">TRUNCATE</literal> on a
+ <literal>Falcon</literal> table did not reset the auto-increment
+ counters and used an inefficient method of deleting existing
+ data.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="22199"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Creating a new table or dropping a database on a newly created
+ <literal>Falcon</literal> database or tablespace raised an
+ error.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="AUTO_INCREMENT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="22564"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Creating a <literal>Falcon</literal> table with an
+ auto-increment column that is not indexed as the first column in
+ a multi-column index would auto-increment. This behavior was
+ different to the behavior in both <literal>MyISAM</literal> and
+ <literal>InnoDB</literal>. <literal>Falcon</literal> now rejects
+ such tables during creation in the same way
+ <literal>InnoDB</literal> does.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="transaction"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29452"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using two simultaneous connections it was possible to create a
+ deadlock situation between two different active transactions on
+ the same <literal>Falcon</literal> table. There is no way to
+ prevent this, but a new parameter,
+ <option>falcon_lock_timeout</option> can set the timeout for
+ deadlocked transactions. The default timeout is 0 (timeouts are
+ disabled).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31005"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <option>falcon_serial_log_dir</option> to set the location
+ of the <literal>Falcon</literal> serial log would have no
+ effect.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32194"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Altering a <literal>Falcon</literal> table to support an auto
+ increment column on a column with existing data and null values
+ would incorrectly update the table and return an incorrect count
+ of the altered rows.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="OPTIMIZE TABLE"/>
+ <manual type="ANALYZE TABLE"/>
+ <manual type="MyISAM"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30495"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ <version ver="5.1.23"/>
+ <version ver="5.0.54"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The options available to the <literal role="stmt">CHECK
+ TABLE</literal> statement were also allowed in
+ <literal role="stmt">OPTIMIZE TABLE</literal> and
+ <literal role="stmt">ANALYZE TABLE</literal> statements, but
+ caused corruption during their execution. These options were
+ never supported for these statements, and an error is now raised
+ if you try to apply these options to these statements.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MERGE"/>
+ <manual type="OPTIMIZE TABLE"/>
+ <manual type="FLUSH TABLES"/>
+ <manual type="LOCK TABLE"/>
+ <manual type="ANALYZE TABLE"/>
+ <manual type="TRUNCATE"/>
+ <manual type="REPAIR TABLE"/>
+ <highlight type="importantchange"/>
+ <highlight type="incompatiblechange"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="19627"/>
+ <fixes bugid="25038"/>
+ <fixes bugid="25700"/>
+ <fixes bugid="26377"/>
+ <fixes bugid="26379"/>
+ <fixes bugid="26867"/>
+ <fixes bugid="27660"/>
+ <fixes bugid="30275"/>
+ <fixes bugid="30491"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A number of problems existed in the implementation of
+ <literal>MERGE</literal> tables that could cause problems. The
+ problems are summarized below:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Bug #26379 - Combination of
+ <literal role="stmt" condition="flush">FLUSH TABLE</literal>
+ and <literal role="stmt">REPAIR TABLE</literal> corrupts a
+ <literal>MERGE</literal> table. This was caused in a number
+ of situations:
+ </para>
+ <orderedlist>
+
+ <listitem>
+ <para>
+ A thread trying to lock a <literal>MERGE</literal> table
+ performs busy waiting while <literal role="stmt">REPAIR
+ TABLE</literal> or a similar table administration task
+ is ongoing on one or more of its MyISAM tables.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A thread trying to lock a <literal>MERGE</literal> table
+ performs busy waiting until all threads that did
+ <literal role="stmt">REPAIR TABLE</literal> 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
+ <literal role="stmt" condition="lock-tables">UNLOCK
+ TABLES</literal> only.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Two <literal role="stmt" condition="flush">FLUSH
+ TABLES</literal> within a <literal role="stmt">LOCK
+ TABLES</literal> segment can invalidate the lock. This
+ does not require a <literal>MERGE</literal> table. The
+ first <literal role="stmt" condition="flush">FLUSH
+ TABLES</literal> can be replaced by any statement that
+ requires other threads to reopen the table. In 5.0 and
+ 5.1 a single
+ <literal role="stmt" condition="flush">FLUSH
+ TABLES</literal> can provoke the problem.
+ </para>
+ </listitem>
+
+ </orderedlist>
+ </listitem>
+
+ <listitem>
+ <para>
+ Bug #26867 - Simultaneously executing
+ <literal role="stmt">LOCK TABLES</literal> and
+ <literal role="stmt">REPAIR TABLE</literal> on a
+ <literal>MERGE</literal> table would result in memory/cpu
+ hogging.
+ </para>
+ <para>
+ Trying DML on a <literal>MERGE</literal> table, which has a
+ child locked and repaired by another thread, made an
+ infinite loop in the server.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Bug #26377 - Deadlock with <literal>MERGE</literal> and
+ <literal role="stmt" condition="flush">FLUSH TABLE</literal>
+ </para>
+ <para>
+ Locking a MERGE table and its children in parent-child order
+ and flushing the child deadlocked the server.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Bug #25038 - Waiting <literal role="stmt">TRUNCATE</literal>
+ </para>
+ <para>
+ Truncating a MERGE child, while the MERGE table was in use,
+ let the truncate fail instead of waiting for the table to
+ become free.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Bug #25700 - <literal>MERGE</literal> base tables get
+ corrupted by <literal>OPTIMIZE/ANALYZE/REPAIR
+ TABLE</literal>
+ </para>
+ <para>
+ Repairing a child of an open <literal>MERGE</literal> table
+ corrupted the child. It was necessary to
+ <literal role="stmt">FLUSH</literal> the child first.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Bug #30275 - <literal>MERGE</literal> tables:
+ <literal role="stmt" condition="flush">FLUSH
+ TABLES</literal> or
+ <literal role="stmt" condition="lock-tables">UNLOCK
+ TABLES</literal> causes server to crash.
+ </para>
+ <para>
+ Flushing and optimizing locked <literal>MERGE</literal>
+ children crashed the server.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Bug #19627 - temporary merge table locking
+ </para>
+ <para>
+ Use of a temporary <literal>MERGE</literal> table with
+ non-temporary children could corrupt the children.
+ </para>
+ <para>
+ Temporary tables are never locked. Creation of tables with
+ non-temporary children of a temporary
+ <literal>MERGE</literal> table is now prohibited.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Bug #27660 - <literal>Falcon</literal>:
+ <literal>MERGE</literal> table possible
+ </para>
+ <para>
+ It was possible to create a <literal>MERGE</literal> table
+ with non-<literal>MyISAM</literal> children.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Bug #30273 - <literal>MERGE</literal> tables: Can't lock
+ file (errno: 155)
+ </para>
+ <para>
+ This was a Windows-only bug. Table administration statements
+ sometimes failed with "Can't lock file (errno: 155)".
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The fix introduces the following changes in behavior:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ This patch changes the behavior of temporary
+ <literal>MERGE</literal> tables. Temporary
+ <literal>MERGE</literal> 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.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ You cannot change the union list of a non-temporary
+ <literal>MERGE</literal> table when LOCK TABLES is in
+ effect. The following does <emphasis>not</emphasis> work:
+<programlisting>
+CREATE TABLE m1 ... ENGINE=MRG_MYISAM ...;
+LOCK TABLES t1 WRITE, t2 WRITE, m1 WRITE;
+ALTER TABLE m1 ... UNION=(t1,t2) ...;
+</programlisting>
+ However, you can do this with a temporary
+ <literal>MERGE</literal> table.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ You cannot create a <literal>MERGE</literal> table with
+ <literal>CREATE ... SELECT</literal>, neither as a temporary
+ <literal>MERGE</literal> table, nor as a non-temporary
+ <literal>MERGE</literal> table. For example, <literal>CREATE
+ TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...;</literal>
+ causes the error message: <errortext>table is not BASE
+ TABLE</errortext>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql_install_db"/>
+ <highlight type="incompatiblechange"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30759"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>mysql_install_db</literal> script could fail to
+ locate some components (including <command>resolveip</command>)
+ during execution if the <option>--basedir</option> option was
+ specified on the command-line or within the
+ <filename>my.cnf</filename> file. This was due to a conflict
+ when comparing the compiled-in values and the supplied values.
+ </para>
+
+ <para>
+ The <literal>--source-install</literal> command-line option to
+ the script has been removed and replaced with the
+ <literal>--srcdir</literal> option.
+ <command>mysql_install_db</command> now locates components
+ either using the compiled-in options, the
+ <option>--basedir</option> option or <option>--srcdir</option>
+ option.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="18431"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.52"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>readline</literal> library has been updated to
+ version 5.2. This addresses issues in the
+ <command>mysql</command> client where history and editing within
+ the client would fail to work as expected.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="REGEXP"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31081"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="op">REGEXP</literal> operations could cause a
+ server crash for character sets such as <literal>ucs2</literal>.
+ Now the arguments are converted to <literal>utf8</literal> if
+ possible, to allow correct results to be produced if the
+ resulting strings contain only 8-bit characters.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ <manual type="loose index scan"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31639"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For queries for which loose index scan is applicable, the
+ optimizer could choose the wrong execution plan for correlated
+ subqueries.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SELECT INTO OUTFILE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31663"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.52"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal>SELECT ... INTO OUTFILE</literal>, if the
+ <literal>ENCLOSED BY</literal> string is empty and the
+ <literal>FIELDS TERMINATED BY</literal> string started with a
+ special character (one of <literal>n</literal>,
+ <literal>t</literal>, <literal>r</literal>,
+ <literal>b</literal>, <literal>0</literal>,
+ <literal>Z</literal>, or <literal>N</literal>), every occurrence
+ of the character within field values would be duplicated.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="views"/>
+ <manual type="SHOW COLUMNS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31662"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.52"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">SHOW COLUMNS</literal> and
+ <literal role="stmt">DESCRIBE</literal> displayed
+ <literal>null</literal> as the column type for a view with no
+ valid definer. This caused <command>mysqldump</command> to
+ produce a non-reloadable dump file for the view.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31450"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.52"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Queries that used the <literal>ref</literal> access method or
+ index-based subquery execution over indexes that have
+ <literal role="type">DECIMAL</literal> columns could fail with
+ an error <literal>Column <replaceable>col_name</replaceable>
+ cannot be null</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="WEIGHT_STRING()"/>
+ </tags>
+
+ <versions>
+ <version ver="5.2.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A new SQL function,
+ <literal role="func">WEIGHT_STRING()</literal>, returns the
+ weight string for an input string. The weight string represents
+ the sorting and comparison value of the input string.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BIGINT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30069"/>
+ </bugs>
+
+ <versions>
+ <version ver="4.1.24"/>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On some 64-bit systems, inserting the largest negative value
+ into a <literal role="type">BIGINT</literal> column resulted in
+ incorrect data.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="AUTO_INCREMENT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31860"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server crashed after insertion of a negative value into an
+ <literal>AUTO_INCREMENT</literal> column of an
+ <literal>InnoDB</literal> table.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql"/>
+ <manual type="show-warnings"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="25146"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <command>mysql --show-warnings</command>, warnings were in
+ some cases not displayed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="option files"/>
+ <highlight type="incompatiblechange"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="20748"/>
+ <seealsobug bugid="38180"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ <version ver="5.0.66"/>
+ <version ver="5.0.67"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message ver="5.0.54">
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ Also, users could not override system-wide settings using
+ <filename>~/.my.cnf</filename> because
+ <filename><replaceable>SYSCONFDIR</replaceable>/my.cnf</filename>
+ was read last. The latter file now is read earlier so that
+ <filename>~/.my.cnf</filename> can override system-wide
+ settings.
+ </para>
+
+ <para>
+ The fix for this problem had a side effect such that on Unix,
+ MySQL programs looked for options in
+ <filename>~/my.cnf</filename> rather than the standard location
+ of <filename>~/.my.cnf</filename>. That problem was addressed as
+ Bug#38180.
+ </para>
+
+ </message>
+
+ <message ver="5.1.23">
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ Also, users could not override system-wide settings using
+ <filename>~/.my.cnf</filename> because
+ <filename><replaceable>SYSCONFDIR</replaceable>/my.cnf</filename>
+ was read last. The latter file now is read earlier so that
+ <filename>~/.my.cnf</filename> can override system-wide
+ settings.
+ </para>
+
+ <para>
+ The fix for this problem had a side effect such that on Unix,
+ MySQL programs looked for options in
+ <filename>~/my.cnf</filename> rather than the standard location
+ of <filename>~/.my.cnf</filename>. That problem was addressed as
+ Bug#38180.
+ </para>
+
+ </message>
+
+ <message ver="6.0.4">
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ Also, users could not override system-wide settings using
+ <filename>~/.my.cnf</filename> because
+ <filename><replaceable>SYSCONFDIR</replaceable>/my.cnf</filename>
+ was read last. The latter file now is read earlier so that
+ <filename>~/.my.cnf</filename> can override system-wide
+ settings.
+ </para>
+
+ <para>
+ The fix for this problem had a side effect such that on Unix,
+ MySQL programs looked for options in
+ <filename>~/my.cnf</filename> rather than the standard location
+ of <filename>~/.my.cnf</filename>. That problem was addressed as
+ Bug#38180.
+ </para>
+
+ </message>
+
+ <message ver="5.0.66">
+
+ <para>
+ An additional correction to the original MySQL 5.0.64 fix was
+ made to normalize directory names before adding them to the list
+ of directories. This prevents <filename>/etc/</filename> and
+ <filename>/etc</filename> from being considered different, for
+ example.
+ </para>
+
+ </message>
+
+ <message ver="5.1.28">
+
+ <para>
+ An additional correction to the original MySQL 5.1.23 fix was
+ made to normalize directory names before adding them to the list
+ of directories. This prevents <filename>/etc/</filename> and
+ <filename>/etc</filename> from being considered different, for
+ example.
+ </para>
+
+ </message>
+
+ <message ver="6.0.6">
+
+ <para>
+ An additional correction to the original MySQL 6.0.4 fix was
+ made to normalize directory names before adding them to the list
+ of directories. This prevents <filename>/etc/</filename> and
+ <filename>/etc</filename> from being considered different, for
+ example.
+ </para>
+
+ </message>
+
+ <message ver="5.0.67">
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ Also, users could not override system-wide settings using
+ <filename>~/.my.cnf</filename> because
+ <filename><replaceable>SYSCONFDIR</replaceable>/my.cnf</filename>
+ was read last. The latter file now is read earlier so that
+ <filename>~/.my.cnf</filename> can override system-wide
+ settings.
+ </para>
+
+ <para>
+ An additional correction was made to normalize directory names
+ before adding them to the list of directories. This prevents
+ <filename>/etc/</filename> and <filename>/etc</filename> from
+ being considered different, for example.
+ </para>
+
+ <para>
+ The fix for this problem had a side effect such that on Unix,
+ MySQL programs looked for options in
+ <filename>~/my.cnf</filename> rather than the standard location
+ of <filename>~/.my.cnf</filename>. That problem is addressed in
+ Bug#38180.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="latin2_czech_cs"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29459"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.2.5"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Use of the <literal>latin2_czech_cs</literal> collation caused a
+ server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="euc-kr"/>
+ <manual type="character sets"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30315"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some valid <literal>euc-kr</literal> characters having the
+ second byte in the ranges <literal>[0x41..0x5A]</literal> and
+ <literal>[0x61..0x7A]</literal> were rejected.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="NDBCLUSTER"/>
+ <manual type="INFORMATION_SCHEMA"/>
+ <manual type="SHOW TABLE STATUS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="11379"/>
+ <seealsobug bugid="32440"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.21"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>TABLE_COMMENT</literal> column of
+ <literal role="is">INFORMATION_SCHEMA.TABLES</literal> and the
+ <literal>Comment</literal> column in the output of
+ <literal role="stmt">SHOW TABLE STATUS</literal> displayed
+ extraneous information for <literal>InnoDB</literal> and
+ <literal>NDBCLUSTER</literal> tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="LOCK TABLES"/>
+ <manual type="IN SHARE MODE"/>
+ <manual type="IN EXCLUSIVE MODE"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <versions>
+ <version ver="5.2.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The syntax for the <literal role="stmt">LOCK TABLES</literal>
+ statement has been extended to support transactional table locks
+ that do not commit transactions automatically. Following
+ <literal>LOCK TABLES ... IN SHARE MODE</literal> or
+ <literal>LOCK TABLES ... IN EXCLUSIVE MODE</literal>, you can
+ access tables not mentioned in the <literal role="stmt">LOCK
+ TABLES</literal> statement. You can now also issue these
+ extended <literal role="stmt">LOCK TABLES</literal> statements
+ many times in succession, adding additional tables to the locked
+ set, and without unlocking any tables that were locked
+ previously. When using <literal role="stmt">LOCK
+ TABLES</literal> with <literal>IN SHARE MODE</literal> or
+ <literal>IN EXCLUSIVE MODE</literal>, tables are not unlocked
+ until the transaction is committed.
+ </para>
+
+ <para>
+ The behavior of <literal role="stmt">LOCK TABLES</literal> when
+ not using <literal>IN SHARE MODE</literal> or <literal>IN
+ EXCLUSIVE MODE</literal> remains unchanged.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql"/>
+ <manual type="comments"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="11230"/>
+ <fixes bugid="26215"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.52"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql</command> stripped comments from statements sent
+ to the server. Now the <option>--comments</option> or
+ <option>--skip-comments</option> option can be used to control
+ whether to retain or strip comments. The default is
+ <option>--skip-comments</option>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SPATIAL index"/>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32125"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.0.50sp1"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>InnoDB</literal> does not support
+ <literal>SPATIAL</literal> indexes, but could crash when asked
+ to handle one. Now an error is returned.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ssl-cipher"/>
+ <manual type="libmysqlclient"/>
+ <manual type="option files"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32429"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>ssl-cipher</literal> values in option files were not
+ being read by <literal>libmysqlclient</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="thread_handling"/>
+ <manual type="SHOW VARIABLES"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28785"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">SHOW VARIABLES</literal> did not correctly
+ display the value of the <literal>thread_handling</literal>
+ system variable.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ALTER EVENT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27407"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For an event with an <literal>ON COMPLETION</literal> value of
+ <literal>PRESERVE</literal>, an <literal role="stmt">ALTER
+ EVENT</literal> statement that specified no <literal>ON
+ COMPLETION</literal> option caused the value to become
+ <literal>NOT PRESERVE</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ALTER EVENT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31539"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <literal role="stmt">ALTER EVENT</literal> to rename a
+ disabled event caused it to become enabled.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="event-scheduler"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31332"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <option>--event-scheduler</option> option without a value
+ disabled the event scheduler. Now it enables the event
+ scheduler.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql-test-run.pl"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30630"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.0.50sp1"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql-test-run.pl</command> could not run
+ <command>mysqld</command> with <literal>root</literal>
+ privileges.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="INFORMATION_SCHEMA"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="19588"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.21"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>INFORMATION_SCHEMA</literal> implementation changes
+ were made that optimize certain types of queries for
+ <literal>INFORMATION_SCHEMA</literal> tables so that they
+ execute more quickly.
+ <xref linkend="information-schema-optimization"/>, provides
+ guidelines on how to take advantage of these optimizations by
+ writing queries that minimize the need for the server to access
+ the filesystem to obtain the information contained in
+ <literal>INFORMATION_SCHEMA</literal> tables. By writing queries
+ that enable the server to avoid directory scans or opening table
+ files, you will obtain better performance.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="with-libevent"/>
+ <manual type="configure"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32156"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When <command>configure</command> was run with
+ <literal>--with-libevent</literal>, <literal>libevent</literal>
+ was not linked statically with <command>mysqld</command>,
+ preventing <command>mysqld</command> from being run with a
+ debugger.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="KILL QUERY"/>
+ <manual type="SLEEP()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32436"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Sending several <literal role="stmt" condition="kill">KILL
+ QUERY</literal> statements to target a connection running
+ <literal>SELECT SLEEP()</literal> could freeze the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="FLUSH TABLES WITH READ LOCK"/>
+ <manual type="locking"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32528"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal role="stmt" condition="flush">FLUSH TABLES WITH
+ READ LOCK</literal>, the server failed to properly detect
+ write-locked tables when running with low-priority updates,
+ resulting in a crash or deadlock.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="GROUP BY"/>
+ <manual type="WITH ROLLUP"/>
+ <manual type="NULL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32558"/>
+ <seealsobug bugid="31095"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Use of a <literal>NULL</literal>-returning <literal>GROUP
+ BY</literal> expression in conjunction with <literal>WITH
+ ROLLUP</literal> could cause a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="DELETE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29136"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For transactional tables, an error during a multiple-table
+ <literal role="stmt">DELETE</literal> statement did not roll
+ back the statement.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="SHA2()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="13174"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Added the <literal role="func">SHA2()</literal> function, which
+ calculates the SHA-2 family of hash functions (SHA-224, SHA-256,
+ SHA-384, and SHA-512). (Contributed by Bill Karwin)
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="DELETE"/>
+ <manual type="subqueries"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32030"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A <literal role="stmt">DELETE</literal> statement with a
+ subquery in the <literal>WHERE</literal> clause would sometimes
+ ignore an error during subquery evaluation and proceed with the
+ delete operation.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="user variables"/>
+ <manual type="CONCAT()"/>
+ <manual type="CONCAT_WS()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31898"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server used unnecessarily large amounts of memory when user
+ variables were used as an argument to
+ <literal role="func">CONCAT()</literal> or
+ <literal role="func">CONCAT_WS()</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="DATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32021"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using dates in the range <literal>'0000-00-01'</literal> to
+ <literal>'0000-00-99'</literal> range in the
+ <literal>WHERE</literal> clause could result in an incorrect
+ result set. (These dates are not in the supported range for
+ <literal role="type">DATE</literal>, but different results for a
+ given query could occur depending on position of records
+ containing the dates within a table.)
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="C API"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31952"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The C API contained several undocumented functions that have
+ been removed:
+ <function>mysql_disable_reads_from_master()</function>,
+ <function>mysql_disable_rpl_parse()</function>,
+ <function>mysql_enable_reads_from_master()</function>,
+ <function>mysql_enable_rpl_parse()</function>,
+ <function>mysql_master_query()</function>,
+ <function>mysql_master_send_query()</function>,
+ <function>mysql_reads_from_master_enabled()</function>,
+ <function>mysql_rpl_parse_enabled()</function>,
+ <function>mysql_rpl_probe()</function>,
+ <function>mysql_rpl_query_type()</function>,
+ <function>mysql_set_master()</function>,
+ <function>mysql_slave_query()</function>, and
+ <function>mysql_slave_send_query()</function>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="INTERVAL()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32560"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="func">INTERVAL()</literal> function
+ incorrectly handled <literal>NULL</literal> values in the value
+ list.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="read_only"/>
+ <manual type="CREATE DATABASE"/>
+ <manual type="DROP DATABASE"/>
+ <manual type="SUPER"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27440"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ With the <literal>read_only</literal> system variable enabled,
+ <literal role="stmt">CREATE DATABASE</literal> and
+ <literal role="stmt">DROP DATABASE</literal> were allowed to
+ users who did not have the <literal role="priv">SUPER</literal>
+ privilege.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CREATE TABLE LIKE"/>
+ <manual type="INFORMATION_SCHEMA"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="25629"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>CREATE TABLE LIKE</literal> did not work when the
+ source table was an <literal>INFORMATION_SCHEMA</literal> table.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CREATE TABLE LIKE"/>
+ <manual type="libmysqld"/>
+ <manual type="lower_case_table_names"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32063"/>
+ </bugs>
+
+ <versions>
+ <version ver="4.1.24"/>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ With <literal role="sysvar">lower_case_table_names</literal>
+ set, <literal>CREATE TABLE LIKE</literal> was treated
+ differently by <literal>libmysqld</literal> than by the
+ non-embedded server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="TEXT"/>
+ <manual type="warnings"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32282"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Assigning a 65,536-byte string to a
+ <literal role="type">TEXT</literal> column (which can hold a
+ maximum of 65,535 bytes) resulted in truncation without a
+ warning. Now a truncation warning is generated.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SQL mode"/>
+ <manual type="DATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31928"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Changing the SQL mode to cause dates with <quote>zero</quote>
+ parts to be considered invalid (such as
+ <literal>'1000-00-00'</literal>) could result in indexed and
+ non-indexed searches returning different results for a column
+ that contained such dates.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysql_odbc_escape_string()"/>
+ <manual type="C API"/>
+ <manual type="SQL injection"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29592"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <function>mysql_odbc_escape_string()</function> C API
+ function has been removed. It has multi-byte character escaping
+ issues, doesn't honor the
+ <literal>NO_BACKSLASH_ESCAPES</literal> SQL mode and is not
+ needed anymore by Connector/ODBC as of 3.51.17.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="INTERVAL()"/>
+ <manual type="parser"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="22312"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The parser treated the <literal role="func">INTERVAL()</literal>
+ function incorrectly, leading to situations where syntax errors
+ could result depending on which side of an arithmetic operator
+ the function appeared.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="KILL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32148"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Killing a statement could lead to a race condition in the
+ server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="Unicode"/>
+ <manual type="utf8"/>
+ <manual type="utf8mb3"/>
+ <manual type="utf16"/>
+ <manual type="utf32"/>
+ <manual type="ucs2"/>
+ <manual type="UTF-8"/>
+ <manual type="UTF-16"/>
+ <manual type="UTF-32"/>
+ <manual type="UCS-2"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The Unicode implementation has been extended to provide support
+ for supplementary characters that lie outside the Basic
+ Multilingual Plane (BMP). Noteworthy features:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>utf16</literal> and <literal>utf32</literal>
+ character sets have been added. These correspond to the
+ UTF-16 and UTF-32 encodings of the Unicode character set,
+ and they both support supplementary characters.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>utf8</literal> character set from previous
+ versions of MySQL has been renamed to
+ <literal>utf8mb3</literal>, to reflect that its encoding
+ uses a maximum of three bytes for multi-byte characters.
+ (Old tables that previously used <literal>utf8</literal>
+ will be reported as using <literal>utf8mb3</literal> after
+ an in-place upgrade to MySQL 6.0, but otherwise work as
+ before.)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The new <literal>utf8</literal> character set in MySQL 6.0
+ is similar to <literal>utf8mb3</literal>, but its encoding
+ allows up to four bytes per character to enable support for
+ supplementary characters.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>ucs2</literal> character set is essentially
+ unchanged except for the inclusion of some newer BMP
+ characters.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ In most respects, upgrading from MySQL 5.1 to 6.0 should present
+ few problems with regard to Unicode usage, although there are
+ some potential areas of incompatibility. Some examples:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ For the variable-length character data types
+ (<literal role="type">VARCHAR</literal> and the
+ <literal role="type">TEXT</literal> types), the maximum
+ length in characters for <literal>utf8</literal> columns is
+ less in MySQL 6.0 than previously.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ For all character data types
+ (<literal role="type">CHAR</literal>,
+ <literal role="type">VARCHAR</literal>, and the
+ <literal role="type">TEXT</literal> types), the maximum
+ number of characters for <literal>utf8</literal> columns
+ that can be indexed is less in MySQL 6.0 than previously.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ Consequently, if you want to upgrade tables from the old
+ <literal>utf8</literal> (now <literal>utf8mb3</literal>) to the
+ current <literal>utf8</literal>, it may be necessary to change
+ some column or index definitions.
+ </para>
+
+ <para>
+ For additional details about the new Unicode character sets and
+ potential incompatibilities, see
+ <xref linkend="charset-unicode"/>, and
+ <xref linkend="charset-unicode-upgrading"/>.
+ </para>
+
+ <para>
+ If you use events, a known issue is that if you upgrade from
+ MySQL 5.1 to 6.0.4 though 6.0.6, the event scheduler will not
+ work, even after you run <command>mysql_upgrade</command>. (This
+ is an issue only for an upgrade, not for a new installation of
+ MySQL 6.0.x.) As of MySQL 6.0.7,
+ <command>mysql_upgrade</command> handles upgrading the system
+ tables properly. If you upgrade to 6.0.4 through 6.0.6, you can
+ work around this upgrading problem by using these instructions:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ In MySQL 5.1, before upgrading, create a dump file
+ containing your <literal>mysql.event</literal> table:
+ </para>
+<programlisting>
+shell> <userinput>mysqldump -uroot -p mysql event > event.sql</userinput>
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ Stop the server, upgrade to MySQL 6.0, and start the server.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Recreate the <literal>mysql.event</literal> table using the
+ dump file:
+ </para>
+<programlisting>
+shell> <userinput>mysql -uroot -p mysql < event.sql</userinput>
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ Run <command>mysql_upgrade</command> to upgrade the other
+ system tables in the <literal>mysql</literal> database:
+ </para>
+<programlisting>
+shell> <userinput>mysql_upgrade -uroot -p</userinput>
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ Restart the server. The event scheduler should run normally.
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ucs2"/>
+ <manual type="character_set_client"/>
+ <manual type="SET NAMES"/>
+ <manual type="SET CHARACTER SET"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31615"/>
+ </bugs>
+
+ <versions>
+ <version ver="4.1.24"/>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>ucs2</literal> does not work as a client character set,
+ but attempts to use it as such were not rejected. Now
+ <literal role="sysvar">character_set_client</literal> cannot be
+ set to <literal>ucs2</literal>. This also affects statements
+ such as <literal>SET NAMES</literal> and <literal>SET CHARACTER
+ SET</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="32514"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.52"/>
+ <version ver="5.0.50sp1"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A build problem introduced in MySQL 5.0.52 was resolved: The x86
+ 32-bit Intel <command>icc</command>-compiled server binary had
+ unwanted dependences on Intel <command>icc</command> runtime
+ libraries.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="LOCK TABLES"/>
+ <manual type="CREATE TRIGGER"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="23713"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A <literal role="stmt">CREATE TRIGGER</literal> statement could
+ cause a deadlock or server crash if it referred to a table for
+ which a table lock had been acquired with
+ <literal role="stmt">LOCK TABLES</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="FLUSH TABLES WITH READ LOCK"/>
+ <manual type="ALTER TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32395"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If a global read lock acquired with
+ <literal role="stmt" condition="flush">FLUSH TABLES WITH READ
+ LOCK</literal> was in effect, executing
+ <literal role="stmt">ALTER TABLE</literal> could cause a server
+ crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="HANDLER"/>
+ <manual type="FLUSH TABLES"/>
+ <manual type="DROP TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31397"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For a table that had been opened with
+ <literal role="stmt">HANDLER</literal> and marked for reopening
+ after being closed with
+ <literal role="stmt" condition="flush">FLUSH TABLES</literal>,
+ <literal role="stmt">DROP TABLE</literal> did not properly
+ discard the handler.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CREATE TABLE LIKE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31479"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Killing a <literal>CREATE TABLE ... LIKE</literal> statement
+ that was waiting for a name lock caused a server crash. When the
+ statement was killed, the server attempted to release locks that
+ were not held.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql"/>
+ <manual type="Unicode"/>
+ <manual type="byte order mark"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29323"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <command>mysql</command> client program now ignores Unicode
+ byte order mark (BOM) characters at the beginning of input
+ files. Previously, it read them and sent them to the server,
+ resulting in a syntax error.
+ </para>
+
+ <para>
+ Presence of a BOM does not cause <command>mysql</command> to
+ change its default character set. To do that, invoke
+ <command>mysql</command> with an option such as
+ <option>--default-character-set=utf8</option>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="DATE"/>
+ <manual type="DATETIME"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32198"/>
+ <seealsobug bugid="27590"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For comparisons of the form <replaceable>date_col OP
+ datetime_const</replaceable> (where
+ <replaceable>OP</replaceable> is
+ <literal role="op" condition="equal">=</literal>,
+ <literal role="op" condition="less-than"><</literal>,
+ <literal role="op" condition="greater-than">></literal>,
+ <literal role="op" condition="less-than-or-equal"><=</literal>,
+ or
+ <literal role="op" condition="greater-than-or-equal">>=</literal>),
+ the comparison is done using
+ <literal role="type">DATETIME</literal> values, per the fix for
+ Bug#27590. However that fix caused any index on
+ <replaceable>date_col</replaceable> not to be used and
+ compromised performance. Now the index is used again.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="MyISAM"/>
+ <manual type="logging"/>
+ <manual type="table corruption"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When the server detects <literal>MyISAM</literal> table
+ corruption, it now writes additional information to the error
+ log, such as the name and line number of the source file, and
+ the list of threads accessing the table. Example: <literal>Got
+ an error from thread_id=1, mi_dynrec.c:368</literal>. This is
+ useful information to include in bug reports.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CREATE TABLE ... SELECT"/>
+ <manual type="privileges"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="20901"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It was possible to execute <literal>CREATE TABLE t1 ... SELECT
+ ... FROM t2</literal> with the
+ <literal role="priv">CREATE</literal> privilege for
+ <literal>t1</literal> and <literal role="priv">SELECT</literal>
+ privilege for <literal>t2</literal>, even in the absence of the
+ <literal role="priv">INSERT</literal> privilege for
+ <literal>t1</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="parser"/>
+ <manual type="out of memory"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31153"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server crashed in the parser when running out of memory.
+ Memory handling in the parser has been improved to gracefully
+ return an error when out-of-memory conditions occur in the
+ parser.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="grant tables"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32219"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.52"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The default grant tables on Windows contained information for
+ host <literal>production.mysql.com</literal>, which should not
+ be there.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqlslap"/>
+ <manual type="RPM"/>
+ <manual type="Linux"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32077"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqlslap</command> was missing from the MySQL 5.1.22
+ Linux RPM packages.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SHOW EVENTS"/>
+ <manual type="INFORMATION_SCHEMA"/>
+ <manual type="EVENTS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32775"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">SHOW EVENTS</literal> and selecting from
+ the <literal role="is">INFORMATION_SCHEMA.EVENTS</literal> table
+ failed if the current database was
+ <literal>INFORMATION_SCHEMA</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="INFORMATION_SCHEMA"/>
+ <manual type="EVENTS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29830"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>LAST_EXECUTED</literal> column of the
+ <literal role="is">INFORMATION_SCHEMA.EVENTS</literal> table now
+ indicates when the event started executing rather than when it
+ finished executing. As a result, the <literal>ENDS</literal>
+ column is never less than <literal>LAST_EXECUTED</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysqlmanager"/>
+ <manual type="Instance Manager"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The Instance Manager (<command>mysqlmanager</command>) has been
+ discontinued and is no longer provided in MySQL releases.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="locking"/>
+ <manual type="transactions"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31444"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>InnoDB</literal> now tracks locking and use of tables
+ by MySQL only after a table has been successfully locked on
+ behalf of a transaction. Previously, the locked flag was set and
+ the table in-use counter was updated before checking whether the
+ lock on the table succeeded. A subsequent failure in obtaining a
+ lock on the table led to an inconsistent state as the table was
+ neither locked nor in use.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33057"/>
+ <seealsobug bugid="11230"/>
+ <seealsobug bugid="26215"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The fix for Bug#11230 and Bug#26215 introduced a significant
+ input-parsing slowdown for the <command>mysql</command> client.
+ This has been corrected.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqlclient.lib"/>
+ <manual type="yaSSL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27861"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.48"/>
+ <version ver="5.0.51"/>
+ <version ver="5.1.22"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Windows, symbols for yaSSL and taocrypt were missing from
+ <filename>mysqlclient.lib</filename>, resulting in unresolved
+ symbol errors for clients linked against that library.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="triggers"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31540"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Spurious duplicate-key errors could occur for multiple-row
+ inserts into an <literal>InnoDB</literal> table that activate a
+ trigger.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="symbolic links"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26811"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Symbolic links on Windows could fail to work.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="UNION"/>
+ <manual type="subqueries"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32036"/>
+ <fixes bugid="32051"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Within a subquery, <literal>UNION</literal> was handled
+ differently than at the top level, which could result in
+ incorrect results or a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <highlight type="partitioning"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="22972"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Falcon</literal> cannot drop a table for which there is
+ a pending transaction, but the error message for such attempts
+ was misleading.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30782"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Improper calculation of <literal role="op">CASE</literal>
+ expression results could lead to value truncation.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="cp932"/>
+ <manual type="CAST()"/>
+ <manual type="ORDER BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32726"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Use of the <literal>cp932</literal> character set with
+ <literal role="func">CAST()</literal> in an <literal>ORDER
+ BY</literal> clause could cause a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="identifiers"/>
+ <manual type="views"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32496"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.52"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The rules for valid column names were being applied differently
+ for base tables and views.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="DATE_ADD()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32180"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="type">DATETIME</literal> arguments specified in
+ numeric form were treated by
+ <literal role="func">DATE_ADD()</literal> as
+ <literal role="type">DATE</literal> values.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="tests"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32221"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Various test program cleanups were made: 1)
+ <command>mytest</command> and <literal>libmysqltest</literal>
+ were removed. 2) <command>bug25714</command> displays an error
+ message when invoked with incorrect arguments or the
+ <option>--help</option> option. 3)
+ <command>mysql_client_test</command> exits cleanly with a proper
+ error status.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="HOUR()"/>
+ <manual type="MINUTE()"/>
+ <manual type="SECOND()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31990"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="func">HOUR()</literal>,
+ <literal role="func">MINUTE()</literal>, and
+ <literal role="func">SECOND()</literal> could return non-zero
+ values for <literal role="type">DATE</literal> arguments.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="INSERT"/>
+ <manual type="DELAYED"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32676"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Specifying a non-existent column for an <literal>INSERT
+ DELAYED</literal> statement caused a server crash rather than
+ producing an error.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="libmysqld"/>
+ <manual type="CLIENT_MULTI_QUERIES"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32624"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Use of <literal>CLIENT_MULTI_QUERIES</literal> caused
+ <literal>libmysqld</literal> to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="libmysqld"/>
+ <manual type="privileges"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Grant table checks failed in <literal>libmysqld</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="yaSSL"/>
+ <highlight type="securityfix"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33814"/>
+ <cve ref="CVE-2008-0226"/>
+ <cve ref="CVE-2008-0227"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.50sp1a"/>
+ <version ver="5.0.51a"/>
+ <version ver="5.0.54a"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ 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.
+ </para>
+
+ <note>
+ <para>
+ The proof-of-concept exploit is freely available on the
+ Internet. Everyone with a vulnerable MySQL configuration is
+ advised to upgrade <emphasis>immediately</emphasis>.
+ </para>
+ </note>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqlslap"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31704"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqlslap</command> failed to commit after the final
+ record load.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="primary key"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31137"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ MySQL declares a <literal>UNIQUE</literal> key as a
+ <literal>PRIMARY</literal> key if it doesn't have
+ <literal>NULL</literal> columns and is not a partial key, and
+ the <literal>PRIMARY</literal> key must alway be the first key.
+ However, in some cases, a non-first key could be reported as
+ <literal>PRIMARY</literal>, leading to an assert failure by
+ <literal>InnoDB</literal>. This is fixed by correcting the key
+ sort order.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MIN()"/>
+ <manual type="MAX()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32268"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="func">MIN()</literal> and
+ <literal role="func">MAX()</literal> could return incorrect
+ results when an index was present if a loose index scan was
+ used.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="type conversion"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32095"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ String-to-double conversion was performed differently when the
+ prepared-statement protocol was used from when it was not.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Mac OS X"/>
+ <manual type="Leopard"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38217"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Corrected a typecast involving <literal>bool</literal> on Mac OS
+ X 10.5 (Leopard), which evaluated differently from earlier Mac
+ OS X versions.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="libmysqld"/>
+ <manual type="query cache"/>
+ <manual type="prepared statements"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30430"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ With <literal>libmysqld</literal>, use of prepared statements
+ and the query cache at the same time caused problems.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30788"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The optimizer incorrectly optimized conditions out of the
+ <literal>WHERE</literal> clause in some queries involving
+ subqueries and indexed columns.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SQL_BUFFER_RESULT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30384"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal>CREATE ... SELECT ... FROM</literal>, where the
+ resulting table contained indexes, adding
+ <literal>SQL_BUFFER_RESULT</literal> to the
+ <literal role="stmt">SELECT</literal> part caused index
+ corruption in the table.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="IRIX"/>
+ <manual type="MIPS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29085"/>
+ </bugs>
+
+ <versions>
+ <version ver="4.1.24"/>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Denormalized double-precision numbers cannot be handled properly
+ by old MIPS pocessors. For IRIX, this is now handled by enabling
+ a mode to use a software workaround.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="KILL"/>
+ <manual type="binary log"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27571"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A race condition between killing a statement and the thread
+ executing the statement could lead to a situation such that the
+ binary log contained an event indicating that the statement was
+ killed, whereas the statement actually executed to completion.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="UDF"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30355"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The optimizer made incorrect assumptions about the value of the
+ <literal>is_member</literal> value for user-defined functions,
+ sometimes resulting in incorrect ordering of UDF results.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BLACKHOLE"/>
+ <manual type="ALTER TABLE"/>
+ <manual type="locking"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30294"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Simultaneous <literal role="stmt">ALTER TABLE</literal>
+ statements for <literal>BLACKHOLE</literal> tables caused 100%
+ CPU use due to locking problems.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="DROP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30152"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If the server crashed during an <literal role="stmt">ALTER
+ TABLE</literal> statement, leaving a temporary file in the
+ database directory, a subsequent <literal role="stmt">DROP
+ DATABASE</literal> statement failed due to the presence of the
+ temporary file.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="libmysqld"/>
+ <manual type="mysql_insert_id()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26921"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="cfunc">mysql_insert_id()</literal> C API
+ function sometimes returned different results for
+ <literal>libmysqld</literal> and
+ <literal>libmysqlclient</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql_insert_id()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="9481"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If an <literal>INSERT ... SELECT</literal> statement is
+ executed, and no automatically generated value is successfully
+ inserted, then <literal role="cfunc">mysql_insert_id()</literal>
+ returns the ID of the last inserted row.
+ </para>
+
+ <para>
+ If no automatically generated value is successfully inserted,
+ then <literal role="cfunc">mysql_insert_id()</literal> returns
+ 0.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CREATE TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33256"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>CREATE TABLE ... SELECT</literal> created tables that
+ for date columns used the obsolete <literal>Field_date</literal>
+ type instead of <literal>Field_newdate</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subquery"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33794"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server crashed when executing a query that had a subquery
+ containing an equality X=Y where Y referred to a named select
+ list expression from the parent select. The server crashed when
+ trying to use the X=Y equality for <literal>ref</literal>-based
+ access.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30363"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Compared to MySQL 5.1, the 6.0 optimizer failed to use join
+ buffering for certain queries, resulting in slower performance
+ for those queries.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="filesort"/>
+ <manual type="subqueries"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33675"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Use of uninitialized memory for <literal>filesort</literal> in a
+ subquery caused a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="parser"/>
+ <manual type="subqueries"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31797"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Name resolution for correlated subqueries and
+ <literal>HAVING</literal> clauses failed to distinguish which of
+ two was being performed when there was a reference to an outer
+ aliased field. This could result in error messages about a
+ <literal>HAVING</literal> clause for queries that had no such
+ clause.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="query cache"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30887"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Resetting the query cache by issuing a <literal>SET GLOBAL
+ query_cache_size=0</literal> statement caused the server to
+ crash if it concurrently was saving a new result set to the
+ query cache.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="enable-pstack"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29836"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqld</command> displayed the
+ <option>--enable-pstack</option> option in its help message even
+ if MySQL was configured without <option>--with-pstack</option>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="stored routines"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33618"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server could crash when <literal>REPEAT</literal> or another
+ control instruction was used in conjunction with labels and a
+ <literal>LEAVE</literal> instruction.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="compound statements"/>
+ <manual type="labels"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33618"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The parser allowed control structures in compound statements to
+ have mismatched beginning and ending labels.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="DOUBLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="21497"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When inserting an extraordinarly large value into a
+ <literal role="type">DOUBLE</literal> column, the value could be
+ truncated in such a way that the new value cannot be reloaded
+ manually or from the output of <command>mysqldump</command>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="math"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="12860"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Zero-padding of exponent values was not the same across
+ platforms.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="math"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="24541"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Data truncated for column
+ <replaceable>col_num</replaceable> at row
+ <replaceable>row_num</replaceable></literal> warnings were
+ generated for some (constant) values that did not have too high
+ precision.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqlcheck"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="25347"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqlcheck -A -r</command> did not correctly identify
+ all tables that needed repairing.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="resolveip"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27427"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>resolveip</command> failed to produce correct results
+ for hostnames that begin with a digit.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="UNION"/>
+ <manual type="subqueries"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32848"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The correct data type for a <literal>NULL</literal> column
+ resulting from a <literal>UNION</literal> could be determined
+ incorrectly in some cases: 1) Not correctly inferred as
+ <literal>NULL</literal> depending on the number of selects; 2)
+ Not inferred correctly as <literal>NULL</literal> if one select
+ used a subquery.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="GROUP_CONCAT()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32798"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For queries containing <literal>GROUP_CONCAT(DISTINCT
+ <replaceable>col_list</replaceable> ORDER BY
+ <replaceable>col_list</replaceable>)</literal>, there was a
+ limitation that the <literal>DISTINCT</literal> columns had to
+ be the same as <literal>ORDER BY</literal> columns. Incorrect
+ results could be returned if this was not true.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="LAST_DAY()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32270"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="func">LAST_DAY()</literal> function returns a
+ <literal role="type">DATE</literal> value, but internally the
+ value did not have the time fields zeroed and calculations
+ involving the value could return incorrect results.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="UPDATE"/>
+ <manual type="NULL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33699"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The UPDATE statement allowed <literal>NULL</literal> to be
+ assigned to <literal>NOT NULL</literal> columns (the default
+ data type value was assigned). An error occurs now.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="filesort"/>
+ <manual type="DECIMAL"/>
+ <manual type="ORDER BY"/>
+ <manual type="ROUND()"/>
+ <manual type="TRUNCATE()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30889"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="func">ROUND(<replaceable>X</replaceable>,<replaceable>D</replaceable>)</literal>
+ or
+ <literal role="func">TRUNCATE(<replaceable>X</replaceable>,<replaceable>D</replaceable>)</literal>
+ for non-constant values of <replaceable>D</replaceable> could
+ crash the server if these functions were used in an
+ <literal>ORDER BY</literal> that was resolved using
+ <literal>filesort</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="DECIMAL"/>
+ <manual type="ORDER BY"/>
+ <manual type="ROUND()"/>
+ <manual type="TRUNCATE()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33143"/>
+ <seealsobug bugid="33402"/>
+ <seealsobug bugid="30617"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal role="type">DECIMAL</literal> columns used with the
+ <literal role="func">ROUND(<replaceable>X</replaceable>,<replaceable>D</replaceable>)</literal>
+ or
+ <literal role="func">TRUNCATE(<replaceable>X</replaceable>,<replaceable>D</replaceable>)</literal>
+ function with a non-constant value of
+ <replaceable>D</replaceable>, adding an <literal>ORDER
+ BY</literal> for the function result produced misordered output.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysqlslap"/>
+ <manual type="set-random-seed"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30793"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.2.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Added the <option>--set-random-seed</option> option to
+ <command>mysqlslap</command> to enable a seed value to be
+ provided for the randomizer.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ORDER BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33697"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>ORDER BY ... DESC</literal> sorts could produce
+ misordered results.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SHOW STATUS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30252"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>Com_create_function</literal> status variable was
+ not incremented properly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="innodb_force_recovery"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28604"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.48"/>
+ <version ver="5.1.21"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Starting the server with an
+ <literal>innodb_force_recovery</literal> value of 4 did not
+ work.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CHECKSUM TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30041"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For tables with <literal role="type">FLOAT</literal> or
+ <literal role="type">DOUBLE</literal> columns,
+ <literal role="stmt">CHECKSUM TABLE</literal> could report
+ different results on master and slave servers.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <bugs>
+ <fixes bugid="31954"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Several undocumented C API functions were removed:
+ <function>mysql_manager_close()</function>,
+ <function>mysql_manager_command()</function>,
+ <function>mysql_manager_connect()</function>,
+ <function>mysql_manager_fetch_line()</function>, and
+ <function>mysql_manager_init()</function>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="thread_handling"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30651"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>thread_handling</literal> system variable was
+ treated as having a <literal>SESSION</literal> value and as
+ being settable at runtime. Now it has only a
+ <literal>GLOBAL</literal> read-only value.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Unicode"/>
+ <manual type="utf16"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32393"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>utf16</literal> columns allowed incorrect Unicode
+ characters inserted through conversion from another Unicode
+ character set.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="latin2_czech_cs"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33452"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For the <literal>latin2_czech_cs</literal> collation, the
+ primary weights for all variants of capital letters
+ <literal>U</literal> and <literal>O</literal> were incorrect
+ (were not equal to the corresponding small letters).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="type conversion"/>
+ </tags>
+
+ <bugs>
+ <seealsobug bugid="12860"/>
+ <seealsobug bugid="21497"/>
+ <seealsobug bugid="26788"/>
+ <seealsobug bugid="24541"/>
+ <seealsobug bugid="34015"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server now includes <literal>dtoa</literal>, a library for
+ conversion between strings and numbers by David M. Gay. In
+ MySQL, this library provides the basis for improved conversion
+ between string or <literal role="type">DECIMAL</literal> values
+ and approximate-value (FLOAT/DOUBLE) numbers:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Consistent conversion results across platforms, which
+ eliminates, for example, Unix versus Windows conversion
+ differences.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Accurate representation of values in cases where results
+ previously did not provide sufficient precision, such as for
+ values close to IEEE limits.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Conversion of numbers to string format with the best
+ possible precision. The precision of <literal>dtoa</literal>
+ is always the same or bettter than that of the standard C
+ library functions.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ Because the conversions produced by this library differ in some
+ cases from previous results, the potential exists for
+ incompatibilities in applications that rely on previous results.
+ For example, applications that depend on a specific exact result
+ from previous conversions might need adjustment to accommodate
+ additional precision.
+ </para>
+
+ <para>
+ For additional information about the properties of
+ <literal>dtoa</literal> conversions, see
+ <xref linkend="type-conversion"/>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysqlimport"/>
+ <manual type="use-threads"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqlimport</command> now has a
+ <option>--use-threads=<replaceable>N</replaceable></option>
+ option for loading data files in parallel using
+ <replaceable>N</replaceable> threads.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysqltest"/>
+ <manual type="do-test"/>
+ <manual type="skip-test"/>
+ </tags>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The argument for the <command>mysql-test-run.pl</command>
+ <option>--do-test</option> and <option>--skip-test</option>
+ options is now interpreted as a Perl regular expression if there
+ is a pattern metacharacter in the argument value. This allows
+ more flexible specification of which tests to perform or skip.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Table_locks_waited"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30331"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>Table_locks_waited</literal> waited variable was
+ not incremented in the cases that a lock had to be waited for
+ but the waiting thread was killed or the request was aborted.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="sql_mode"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32633"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.4"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Tables in the <literal>mysql</literal> database that stored the
+ current <literal>sql_mode</literal> value as part of stored
+ program definitions were not updated with newer mode values
+ (<literal>NO_ENGINE_SUBSTITUTION</literal>,
+ <literal>PAD_CHAR_TO_FULL_LENGTH</literal>). This causes various
+ problems defining stored programs if those modes were included
+ in the current <literal>sql_mode</literal> value.
+ </para>
+
+ </message>
+
+ <message ver="6.0.4">
+
+ <para>
+ An issue with the <literal>NO_ENGINE_SUBSTITUTION</literal>
+ <literal>sql_mode</literal> database can cause the creation of
+ stored routines to fail. If you are having problems with
+ creating stored routines while using this
+ <literal>sql_mode</literal> value, remove this value from your
+ <literal>sql_mode</literal> setting.
+ </para>
+
+ </message>
+
+ <message ver="5.1.23">
+
+ <para>
+ An issue with the <literal>NO_ENGINE_SUBSTITUTION</literal>
+ <literal>sql_mode</literal> database can cause the creation of
+ stored routines to fail. If you are having problems with
+ creating stored routines while using this
+ <literal>sql_mode</literal> value, remove this value from your
+ <literal>sql_mode</literal> setting.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SHOW ENGINE INNODB STATUS"/>
+ <manual type="SHOW ENGINE INNODB MUTEX"/>
+ <manual type="PROCESS"/>
+ <manual type="SUPER"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32710"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="stmt" condition="show-engine">SHOW ENGINE
+ INNODB STATUS</literal> and
+ <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB
+ MUTEX</literal> statements incorrectly required the
+ <literal role="priv">SUPER</literal> privilege rather than the
+ <literal role="priv">PROCESS</literal> privilege.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SHOW OPEN TABLES"/>
+ <manual type="stored functions"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34166"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Use of stored functions in the <literal>WHERE</literal> clause
+ for <literal role="stmt">SHOW OPEN TABLES</literal> caused a
+ server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="prepared statements"/>
+ <manual type="INT UNSIGNED"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33798"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Large unsigned integers were improperly handled for prepared
+ statements, resulting in truncation or conversion to negative
+ numbers.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="FEDERATED"/>
+ <manual type="FLOAT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34015"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Updates of floating-point columns in
+ <literal>FEDERATED</literal> tables could produce incorrect
+ results.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="clients"/>
+ <manual type="assertion failure"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34298"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Windows, client programs generated assertion failures.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ucs2"/>
+ <manual type="NDB"/>
+ <highlight type="replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29562"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Replication crashed with the <literal>NDB</literal> storage
+ engine when <command>mysqld</command> was started with
+ <option>--character-set-server=ucs2</option>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Vista"/>
+ <manual type="MySQLInstanceConfig.exe"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="22563"/>
+ <seealsobug bugid="24732"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.51a"/>
+ <version ver="5.0.56"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For Windows Vista, <command>MySQLInstanceConfig.exe</command>
+ did not include a proper manifest enabling it to run with
+ administrative privileges.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysqltest"/>
+ <manual type="mkdir"/>
+ <manual type="rmdir"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31004"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqltest</command> now has <literal>mkdir</literal>
+ and <literal>rmdir</literal> commands for creating and removing
+ directories.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="LOAD DATA INFILE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30435"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Replication of <literal role="stmt" condition="load-data">LOAD
+ DATA INFILE</literal> could fail when
+ <literal>read_buffer_size</literal> was larger than
+ <literal role="sysvar">max_allowed_packet</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="stored routines"/>
+ <manual type="warnings"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="21801"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Warnings for deprecated syntax constructs used in stored
+ routines make sense to report only when the routine is being
+ created, but they were also being reported when the routine was
+ parsed for loading into the execution cache. Now they are
+ reported only at routine creation time.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="UPDATE"/>
+ <manual type="assertion failure"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30763"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.54"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A multiple-table <literal role="stmt">UPDATE</literal> involving
+ transactional and non-transactional tables caused an assertion
+ failure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="UNION"/>
+ <manual type="INTO"/>
+ <manual type="SELECT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32858"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>UNION</literal> constructs cannot contain
+ <literal>SELECT ... INTO</literal> except in the final
+ <literal role="stmt">SELECT</literal>. However, if a
+ <literal>UNION</literal> was used in a subquery and an
+ <literal>INTO</literal> clause appeared in the top-level query,
+ the parser interpreted it as having appeared in the
+ <literal>UNION</literal> and raised an error.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="views"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33133"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some valid <literal role="stmt">SELECT</literal> statements
+ could not be used as views due to incorrect column reference
+ resolution.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="ndbd"/>
+ <manual type="ndb_mgmd"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34642"/>
+ </bugs>
+
+ <versions>
+ <version ver="4.1.24"/>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24-ndb-6.2.16"/>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <command>ndbd</command> and <command>ndb_mgmd</command> man
+ pages have been reclassified from volume 1 to volume 8.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="threads"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An alternative thread model is available for dealing with the
+ issues that occur with the original one-thread-per-client model
+ when scaling to large numbers of simultaneous connections. This
+ model uses thread pooling:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Connection manager threads do not dedicate a thread to each
+ client connection. Instead, the connection is added to the
+ set of existing connection sockets. The server collects
+ input from these sockets and when a complete request has
+ been received from a given client, it is queued for service.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The server maintains a pool of service threads to process
+ requests. When a queued request is waiting and there is an
+ available (not busy) service thread in the pool, the request
+ is given to the thread to be handled. After processing the
+ request, the service thread becomes available to process
+ other requests.
+ </para>
+ <para>
+ Service threads are created at server startup and exist
+ until the server terminates. A given service thread is not
+ tied to a specific client connection and the requests that
+ it processes over time may originate from different client
+ connections.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The pool of service threads has a fixed size, so the amount
+ of memory required for it does not increase as the number of
+ client connections increases.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ For information about choosing one thread model over the other
+ and tuning the parameters that control thread resources, see
+ <xref linkend="connection-threads"/>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysqldump"/>
+ <manual type="dump-slave"/>
+ <manual type="apply-slave-statements"/>
+ <manual type="include-master-host-port"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="8368"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Three options were added to <command>mysqldump</command> make it
+ easier to generate a dump from a slave server.
+ <option>--dump-slave</option> is similar to
+ <option>--master-data</option>, but the
+ <literal role="stmt">CHANGE MASTER TO</literal> statement
+ contains binary log coordinates for the slave's master host, not
+ the slave itself. <option>--apply-slave-statements</option>
+ causes <literal role="stmt">STOP SLAVE</literal> and
+ <literal role="stmt">START SLAVE</literal> statements to be
+ added before the <literal role="stmt">CHANGE MASTER TO</literal>
+ statement and at the end of the output, respectively.
+ <option>--include-master-host-port</option> causes the
+ <literal role="stmt">CHANGE MASTER TO</literal> statement to
+ include <literal>MASTER_PORT</literal> and
+ <literal>MASTER_HOST</literal> options for the slave's master.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="views"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29477"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Views were treated as insertable even if some base table columns
+ with no default value were omitted from the view definition.
+ (This is contrary to the condition for insertability that a view
+ must contain all columns in the base table that do not have a
+ default value.)
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqltest_embedded.exe"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32044"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Windows, <command>mysqltest_embedded.exe</command> did not
+ properly execute the <literal>send</literal> command.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ <manual type="subqueries"/>
+ <manual type="semi-join"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31040"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An assertion failure occurred for queries containing two
+ subqueries if both subqueries were evaluated using a semi-join
+ strategy.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="foreign keys"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="18942"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">DROP DATABASE</literal> did not drop
+ orphaned <literal>FOREIGN KEY</literal> constraints.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql_config"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="21158"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql_config</command> output did not include
+ <literal>-lmygcc</literal> on some platforms when it was needed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <highlight type="partitioning"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33349"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal>InnoDB</literal> tables, there was a race condition
+ involving the data dictionary and repartitioning.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SHOW STATUS"/>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32083"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">SHOW STATUS</literal> caused a server crash
+ if <literal>InnoDB</literal> had not been initialized.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql_explain_log"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34339"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql_explain_log</command> concatenated multiple-line
+ statements, causing malformed results for statements that
+ contained SQL comments beginning with <literal>--</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33841"/>
+ </bugs>
+
+ <versions>
+ <version ver="4.1.24"/>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An internal buffer in <command>mysql</command> was too short.
+ Overextending it could cause stack problems or segmentation
+ violations on some architectures. (This is not a problem that
+ could be exploited to run arbitrary code.)
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31745"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <command>mysqld</command> crash handler failed on Windows.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqld_safe"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32679"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqld_safe</command> looked for error messages in the
+ wrong location.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31929"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Windows, the build process failed with four parallel build
+ threads.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqlhotcopy"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28460"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqlhotcopy</command> silently skipped databases with
+ names consisting of two alphanumeric characters.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql"/>
+ <manual type="completion"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="24624"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql</command> did not use its completion table. Also,
+ the table contained few entries.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="innodb_adaptive_hash_index"/>
+ </tags>
+
+ <versions>
+ <version ver="5.0.52"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The use of <literal>InnoDB</literal> hash indexes now can be
+ controlled by setting the new
+ <literal>innodb_adaptive_hash_index</literal> system variable at
+ server startup. By default, this variable is enabled. See
+ <xref linkend="innodb-adaptive-hash"/>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ODBC"/>
+ <manual type="OJ"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28317"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.2.14"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Previously, the parser accepted the ODBC <literal>{ OJ ... LEFT
+ OUTER JOIN ...}</literal> syntax for writing left outer joins.
+ The parser now allows <literal>{ OJ ... }</literal> to be used
+ to write other types of joins, such as <literal>INNER
+ JOIN</literal> or <literal>RIGHT OUTER JOIN</literal>. This
+ helps with compatibility with some third-party applications, but
+ is not official ODBC syntax.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="ALTER TABLE"/>
+ <manual type="ORDER BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26447"/>
+ <seealsobug bugid="35850"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It makes no sense to attempt to use <literal>ALTER TABLE ...
+ ORDER BY</literal> to order an <literal>InnoDB</literal> table
+ if there is a user-defined clustered index, because rows are
+ always ordered by the clustered index. Such attempts now are
+ ignored and produce a warning.
+ </para>
+
+ <para>
+ Also, in some cases, <literal>InnoDB</literal> incorrectly used
+ a secondary index when the clustered index would produce a
+ faster scan. <literal role="stmt">EXPLAIN</literal> output now
+ indicates use of the clustered index (for tables that have one)
+ as lines with a <literal>type</literal> value of
+ <literal>index</literal>, a <literal>key</literal> value of
+ <literal>PRIMARY</literal>, and without <literal>Using
+ index</literal> in the <literal>Extra</literal> value.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="privileges"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="17303"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.51a"/>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>MySQLInstanceConfig.exe</command> failed to grant
+ certain privileges to the <literal>'root'@'%'</literal> account.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="Vista"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34381"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Client applications could not connect to the server on Windows
+ Vista because the server was creating an IPv6-only TCP/IP
+ socket.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="shared memory"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="24731"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.44"/>
+ <version ver="5.1.20"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When <command>mysqld</command> was run as a Windows service,
+ shared memory objects were not created in the global namespace
+ and could not be used by clients to connect.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="foreign key"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="21704"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Renaming a column that appeared in a foreign key definition did
+ not update that definition with the new column name. This
+ occurred with both referenced and referencing tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="events"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="22738"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ After stopping and starting the event scheduler, disabled events
+ could remain in the execution queue.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql_install_db"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31315"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql_install_db</command> failed if the default
+ storage engine was <literal>NDB</literal>. Now it explicitly
+ uses <literal>MyISAM</literal> as the storage engine when
+ running <command>mysqld --bootstrap</command>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="C API"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34655"/>
+ <seealsobug bugid="12713"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In MySQL 5.1.23, the <literal>last_errno</literal> and
+ <literal>last_error</literal> members of the
+ <literal>NET</literal> structure in
+ <filename>mysql_com.h</filename> were renamed to
+ <literal>client_last_errno</literal> and
+ <literal>client_last_error</literal>. This was found to cause
+ problems for connectors that use the internal
+ <literal>NET</literal> structure for error handling. The change
+ has been reverted.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32149"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>InnoDB</literal> adaptive hash latches could be held
+ too long, resulting in a server crash. This fix may also provide
+ significant performance improvements on systems on which many
+ queries using filesorts with temporary tables are being
+ performed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="make_binary_distribution"/>
+ <manual type="ICC"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33536"/>
+ </bugs>
+
+ <versions>
+ <version ver="4.1.24"/>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>make_binary_distribution</command> passed the
+ <option>--print-libgcc-file</option> option to the C compiler,
+ but this does not work with the <command>ICC</command> compiler.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql_change_user()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31222"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="cfunc">mysql_change_user()</literal> C API
+ function caused global
+ <literal>Com_<replaceable>xxx</replaceable></literal> status
+ variable values to be incorrect.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysql"/>
+ <manual type="--auto-vertical-output"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26780"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Added the <option>--auto-vertical-output</option> option to
+ <command>mysql</command> which causes result sets to be
+ displayed vertically if they are too wide for the current
+ window, and using normal tabular format otherwise. (This applies
+ to statements terminated by <literal>;</literal> or
+ <literal>\G</literal>.)
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQLInstanceConfig.exe"/>
+ <manual type="Vista"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="24853"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.51a"/>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For Vista installs, <command>MySQLInstanceConfig.exe</command>
+ did not add the default MySQL port to the firewall exceptions.
+ It now provides a checkbox that enables the user a choice of
+ whether to do this.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SIGHUP"/>
+ <manual type="logging"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33065"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ After receiving a <literal>SIGHUP</literal> signal, the server
+ could crash, and user-specified log options were ignored when
+ reopening the logs.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="read_only"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31947"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A variable named <literal>read_only</literal> could be declared
+ even though that is a reserved word.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Mac OS X"/>
+ <manual type="gdb"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="21567"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Mac OS X, <command>mysqld</command> did not react to Ctrl-C
+ when run under <command>gdb</command>, even when run with the
+ <option>--gdb</option> option.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SHOW COLUMNS"/>
+ <manual type="locking"/>
+ <manual type="TEMPORARY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="23588"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">SHOW COLUMNS</literal> on a
+ <literal>TEMPOARY</literal> table caused locking issues.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="C API"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="25097"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The client library had no way to return an error if no
+ connection had been established. This caused problems such as
+ <literal role="cfunc">mysql_library_init()</literal> failing
+ silently if no <filename>errmsg.sys</filename> file was
+ available.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="privileges"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31194"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When sorting privilege table rows, the server treated escaped
+ wildcard characters (<literal>\%</literal> and
+ <literal>\_</literal>) the same as unescaped wildcard characters
+ (<literal>%</literal> and <literal>_</literal>), resulting in
+ incorrect row ordering.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysql_tableinfo"/>
+ <manual type="INFORMATION_SCHEMA"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.0"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <command>mysql_tableinfo</command> script has been removed.
+ Information similar to that produced by this script is available
+ from tables in the <literal>INFORMATION_SCHEMA</literal>
+ database.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="RESTORE"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Two new statements, <literal role="stmt">BACKUP
+ DATABASE</literal> and <literal role="stmt">RESTORE</literal>,
+ have been added for backup and restore operations. See
+ <xref linkend="backup-database-restore"/>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SSL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33050"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When MySQL was built with OpenSSL, the SSL library was not
+ properly initialized with information of which endpoint it was
+ (server or client), causing connection failures.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="RPM"/>
+ <manual type="installation"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28555"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For upgrading to a new major version using RPM packages (such as
+ 4.1 to 5.0), if the installation procedure found an existing
+ MySQL server running, it could fail to shut down the old server,
+ but also erroneously removed the server's socket file. Now the
+ procedure checks for an existing server package from a different
+ vendor or major MySQL version. In such case, it refuses to
+ install the server and recommends how to safely remove the old
+ packages before installing the new ones.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="foreign key"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34455"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The parser accepted illegal syntax in a <literal>FOREIGN
+ KEY</literal> clause:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Multiple <literal>MATCH</literal> clauses.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Multiple <literal>ON DELETE</literal> clauses.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Multiple <literal>ON UPDATE</literal> clauses.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>MATCH</literal> clauses specified after <literal>ON
+ UPDATE</literal> or <literal>ON DELETE</literal>. In case of
+ multiple redundant clauses, this leads to confusion, and
+ implementation-dependent results.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ These illegal syntaxes are now properly rejected. Existing
+ applications that used them will require adjustment.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="prepared statements"/>
+ <manual type="logging"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28386"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ No information was written to the general query log for the
+ <literal>COM_STMT_CLOSE</literal>,
+ <literal>COM_STMT_RESET</literal>, and
+ <literal>COM_STMT_SEND_LONG_DATA</literal> commands. (These
+ occur when a client invokes the
+ <literal role="cfunc">mysql_stmt_close()</literal>,
+ <literal role="cfunc">mysql_stmt_reset()</literal> and
+ <literal role="cfunc">mysql_stmt_send_long_data()</literal> C
+ API functions.)
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Leopard"/>
+ <manual type="Mac OS X"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28854"/>
+ </bugs>
+
+ <versions>
+ <version ver="4.1.24"/>
+ <version ver="5.0.51b"/>
+ <version ver="5.0.58"/>
+ <version ver="5.1.24"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The MySQL preferences pane did not work to start or stop MySQL
+ on Mac OS X 10.5 (Leopard).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="UPDATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29157"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>InnoDB</literal> could return an incorrect rows-updated
+ value for <literal role="stmt">UPDATE</literal> statements.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="DEFINER"/>
+ <manual type="views"/>
+ <manual type="triggers"/>
+ <manual type="events"/>
+ <manual type="stored procedures"/>
+ <manual type="stored functions"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="21854"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For views or stored programs created with an invalid
+ <literal>DEFINER</literal> value, the error message was
+ confusing (did not tie the problem to the
+ <literal>DEFINER</literal> clause) and has been improved.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="privileges"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="25175"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server uses less memory when loading privileges containing
+ table grants. (Patch provided by Google.)
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="query cache"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="25132"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>Qcache_free_blocks</literal> status variable did
+ not display a value of 0 if the query cache was disabled.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="YEAR"/>
+ <manual type="DEFAULT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34274"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>DEFAULT 0</literal> was not allowed for the
+ <literal role="type">YEAR</literal> data type.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="utf8_general_ci"/>
+ <manual type="Unicode"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27877"/>
+ <seealsobug bugid="37046"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message ver="5.1.24">
+
+ <para>
+ The <literal>utf8_general_ci</literal> and
+ <literal>ucs2_general_ci</literal> collations did not sort the
+ letter "U+00DF SHARP S" equal to <literal>'s'</literal>.
+ </para>
+
+ <para>
+ As a result of this fix, any indexes on columns that use these
+ collations (but only columns that use SHARP S) must be rebuilt
+ when upgrading to 5.1.24 or higher. To do this, use
+ <literal role="stmt">ALTER TABLE</literal> to drop and re-add
+ the indexes, or <command>mysqldump</command> to dump the
+ affected tables and <command>mysql</command> to reload the dump
+ file.
+ </para>
+
+ </message>
+
+ <message ver="6.0.5">
+
+ <para>
+ The <literal>utf8_general_ci</literal> and
+ <literal>ucs2_general_ci</literal> collations did not sort the
+ letter "U+00DF SHARP S" equal to <literal>'s'</literal>.
+ </para>
+
+ <para>
+ As a result of this fix, any indexes on columns that use these
+ collations (but only columns that use SHARP S) must be rebuilt
+ when upgrading to 6.0.5 or higher. To do this, use
+ <literal role="stmt">ALTER TABLE</literal> to drop and re-add
+ the indexes, or <command>mysqldump</command> to dump the
+ affected tables and <command>mysql</command> to reload the dump
+ file.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="event scheduler"/>
+ <manual type="max_connections"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33507"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Threads created by the event scheduler were incorrectly counted
+ against the <literal role="sysvar">max_connections</literal>
+ thread limit, which could lead to client lockout.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Max_used_connections"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35074"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23-ndb-6.0.5"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Non-connection threads were being counted in the value of the
+ <literal>Max_used_connections</literal> status variable.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="query cache"/>
+ <manual type="concurrent inserts"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33756"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Disabling concurrent inserts caused some cacheable queries not
+ to be saved in the query cache.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="WEIGHT_STRING()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33663"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="func">WEIGHT_STRING()</literal> function
+ returned incorrect results for column values when earlier column
+ values were <literal>NULL</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="WEIGHT_STRING()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33077"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The weight for supplementary Unicode characters should be
+ <literal>0xFFFD</literal>, but the
+ <literal role="func">WEIGHT_STRING()</literal> function returned
+ <literal>0x0DC6</literal> instead.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="storage engines"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="22708"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server produced a confusing error message when attempting to
+ open a table that required a storage engine that was not loaded.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="logging"/>
+ <manual type="log tables"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="23924"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Logging of statements to log tables was incorrect for statements
+ that contained <literal>utf8</literal>-incompatible binary
+ strings. Incompatible sequences are hex-encoded now.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="symbolic links"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="25677"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When symbolic links were disabled, either with a server startup
+ option or by enabling the <literal>NO_DIR_IN_CREATE</literal>
+ SQL mode, <literal role="stmt">CREATE TABLE</literal> silently
+ ignored the <literal>DATA DIRECTORY</literal> and <literal>INDEX
+ DIRECTORY</literal> table options. Now the server issues a
+ warning if symbolic links are disabled when these table options
+ are used.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="23097"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For distributions compiled with the bundled
+ <literal>libedit</literal> library, there were difficulties
+ using the <command>mysql</command> client to enter input for
+ non-ASCII or multi-byte characters.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SLEEP()"/>
+ <manual type="Mac OS X"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33304"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="func">SLEEP(0)</literal> failed to return on
+ 64-bit Mac OS X due to a bug in
+ <function>pthread_cond_timedwait()</function>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="innodb_flush_method"/>
+ <manual type="fdatasync"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Formerly it was possible to specify an
+ <literal>innodb_flush_method</literal> value of
+ <literal>fdatasync</literal> to obtain the default flush
+ behavior of using <literal>fdatasync()</literal> for flushing.
+ This is no longer possible because it can be confusing that a
+ value of <literal>fdatasync</literal> causes use of
+ <literal>fsync()</literal> rather than
+ <literal>fdatasync()</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="views"/>
+ <manual type="WITH CHECK OPTION"/>
+ <manual type="GROUP BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="9801"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The grammar for <literal>GROUP BY</literal>, when used with
+ <literal>WITH CUBE</literal> or <literal>WITH ROLLUP</literal>,
+ caused a conflict with the grammar for view definitions that
+ included <literal>WITH CHECK OPTION</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26243"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Windows, for distributions built with debugging support,
+ <command>mysql</command> could crash if the user typed
+ Control-C.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ORDER BY"/>
+ <manual type="ONLY_FULL_GROUP_BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27219"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In <literal>ORDER BY</literal> clauses, mixing aggregate
+ functions and non-grouping columns is not allowed if the
+ <literal>ONLY_FULL_GROUP_BY</literal> SQL mode is enabled.
+ However, in some cases, no error was thrown because of
+ insufficient checking.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="TINYBLOB"/>
+ <manual type="TINYTEXT"/>
+ <manual type="ALTER TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34300"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal>InnoDB</literal>, exporting and importing a table
+ could corrupt <literal role="type">TINYBLOB</literal> columns,
+ and a subsequent <literal role="stmt">ALTER TABLE</literal>
+ could corrupt <literal role="type">TINYTEXT</literal> columns as
+ well.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="TEMPORARY table"/>
+ <manual type="DELETE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35392"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For a <literal>TEMPORARY</literal> table,
+ <literal role="stmt">DELETE</literal> with no
+ <literal>WHERE</literal> clause could fail when preceded by
+ <literal role="stmt">DELETE</literal> statements with a
+ <literal>WHERE</literal> clause.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="primary key"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34731"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For an indexed integer column
+ <replaceable>col_name</replaceable> and a value
+ <replaceable>N</replaceable> that is one greater than the
+ maximum value allowed for the data type of
+ <replaceable>col_name</replaceable>, conditions of the form
+ <literal>WHERE <replaceable>col_name</replaceable> <
+ <replaceable>N</replaceable></literal> failed to return rows
+ where the value of <replaceable>col_name</replaceable> is
+ <literal><replaceable>N</replaceable> - 1</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="LOAD DATA INFILE"/>
+ <manual type="views"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35469"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <literal role="stmt" condition="load-data">LOAD DATA
+ INFILE</literal> with a view could crash the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="perror"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="23028"/>
+ <fixes bugid="25177"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>perror</command> reported incomplete or inaccurate
+ information.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="AUTO_INCREMENT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34335"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>InnoDB</literal> could crash if overflow occurred for
+ an <literal>AUTO_INCREMENT</literal> column.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="fsync()"/>
+ <manual type="ENOLCK"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34823"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If <function>fsync()</function> returned
+ <literal>ENOLCK</literal>, <literal>InnoDB</literal> could treat
+ this as fatal and cause abnormal server termination.
+ <literal>InnoDB</literal> now retries the operation.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ORDER BY"/>
+ <manual type="indexes"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35206"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Queries could return different results depending on whether
+ <literal>ORDER BY</literal> columns were indexed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="ALTER TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35220"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal>InnoDB</literal> tables, <literal>ALTER TABLE
+ DROP</literal> failed if the name of the column to be dropped
+ began with <quote>foreign</quote>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="plugins"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33345"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Loading plugins via command-line options to
+ <command>mysqld</command> could cause an assertion failure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQLInstanceConfig.exe"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="19797"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>MySQLInstanceConfig.exe</command> could lose the
+ <literal>innodb_data_home_dir</literal> setting when
+ reconfiguring an instance.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="bool"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26461"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <filename>config-win.h</filename> unconditionally defined
+ <literal>bool</literal> as <literal role="type">BOOL</literal>,
+ causing problems on systems where <literal>bool</literal> is 1
+ byte and <literal role="type">BOOL</literal> is 4 bytes.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Mac OS X"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="25008"/>
+ </bugs>
+
+ <versions>
+ <version ver="4.1.24"/>
+ <version ver="5.0.51b"/>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Mac OS X, the StartupItem for MySQL did not work.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="INFORMATION_SCHEMA"/>
+ <manual type="REFERENTIAL_CONSTRAINTS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35406"/>
+ <seealsobug bugid="35108"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Selecting from
+ <literal role="is">INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS</literal>
+ could cause a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35352"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If the server crashed with an <literal>InnoDB</literal> error
+ due to unavailability of undo slots, errors could persist during
+ rollback when the server was restarted: There are two
+ <literal>UNDO</literal> slot caches (for
+ <literal role="stmt">INSERT</literal> and
+ <literal role="stmt">UPDATE</literal>). If all slots end up in
+ one of the slot caches, a request for a slot from the other slot
+ cache would fail. This can happen if the request is for an
+ <literal role="stmt">UPDATE</literal> slot and all slots are in
+ the <literal role="stmt">INSERT</literal> slot cache, or vice
+ versa.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34928"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For some queries, the optimizer used an ordered index scan for
+ <literal>GROUP BY</literal> or <literal>DISTINCT</literal> when
+ it was supposed to use a loose index scan, leading to incorrect
+ results.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="stored programs"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="8759"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The parser incorrectly allowed <literal>SQLSTATE
+ '00000'</literal> to be specified for a condition handler. (This
+ is incorrect because the condition must be a failure condition
+ and <literal>'00000'</literal> indicates success.)
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="stored programs"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36510"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The parser incorrectly allowed MySQL error code 0 to be
+ specified for a condition handler. (This is incorrect because
+ the condition must be a failure condition and 0 indicates
+ success.)
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql_insert_id()"/>
+ <manual type="AUTO_INCREMENT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34889"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Under some circumstances, the value of
+ <literal role="cfunc">mysql_insert_id()</literal> following a
+ <literal>SELECT ... INSERT</literal> statement could return an
+ incorrect value. This could happen when the last <literal>SELECT
+ ... INSERT</literal> did not involve an
+ <literal>AUTO_INCREMENT</literal> column, but the value of
+ <literal role="cfunc">mysql_insert_id()</literal> was changed by
+ some previous statements.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="GROUP_CONCAT()"/>
+ <manual type="subqueries"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34747"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A memory-handling error associated with use of
+ <literal role="func">GROUP_CONCAT()</literal> in subqueries
+ could result in a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34830"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Table and database names were mixed up in some places of the
+ subquery transformation procedure. This could affect debugging
+ trace output and further extensions of that procedure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="31781"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If an error occurred during file creation, the server sometimes
+ did not remove the file, resulting in an unused file in the
+ filesystem.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30622"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If the optimizer used a multi-read-range access method for index
+ lookups, incorrect results could occur for rows that contained
+ any of the <literal role="type">BLOB</literal> or
+ <literal role="type">TEXT</literal> data types.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="PAD_CHAR_TO_FULL_LENGTH"/>
+ <manual type="sql_mode"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.20"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Added a new <literal>PAD_CHAR_TO_FULL_LENGTH</literal> SQL mode.
+ By default, trailing spaces are trimmed from
+ <literal role="type">CHAR</literal> column values on retrieval.
+ If <literal>PAD_CHAR_TO_FULL_LENGTH</literal> is enabled,
+ trimming does not occur and retrieved
+ <literal role="type">CHAR</literal> values are padded to their
+ full length. This mode does not apply to
+ <literal role="type">VARCHAR</literal> columns, for which
+ trailing spaces are retained on retrieval.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="PAD_CHAR_TO_FULL_LENGTH"/>
+ <manual type="sql_mode"/>
+ <manual type="privileges"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32753"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Enabling the <literal>PAD_CHAR_TO_FULL_LENGTH</literal> SQL mode
+ caused privilege-loading operations (such as
+ <literal role="stmt" condition="flush">FLUSH
+ PRIVILEGES</literal>) to include trailing spaces from grant
+ table values stored in <literal role="type">CHAR</literal>
+ columns. Authentication for incoming connections failed as a
+ result. Now privilege loading does not include trailing spaces,
+ regardless of SQL mode.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="debugging"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33252"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For binary <filename>.tar.gz</filename> packages,
+ <command>mysqld</command> and other binaries now are compiled
+ with debugging symbols included to enable easier use with a
+ debugger. If you do not need debugging symbols and are short on
+ disk space, you can use <command>strip</command> to remove the
+ symbols from the binaries.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQLInstanceConfig.exe"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30823"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Manifest problems prevented
+ <command>MySQLInstanceConfig.exe</command> from running on
+ Windows Vista.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CAST()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34512"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="func">CAST(AVG(<replaceable>arg</replaceable>) AS
+ DECIMAL)</literal> produced incorrect results for
+ non-<literal role="type">DECIMAL</literal> arguments.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="header files"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="23839"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The MySQL header files contained some duplicate macro
+ definitions that could cause compilation problems.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="row constructor"/>
+ <manual type="subqueries"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34763"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Queries such as <literal>SELECT ROW(1, 2) IN (SELECT t1.a, 2)
+ FROM t1 GROUP BY t1.a</literal> (combining row constructors and
+ subqueries in the <literal>FROM</literal> clause) could lead to
+ assertion failure or unexpected error messages.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="shared memory"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="24992"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For Windows 64-bit builds, enabling shared-memory support caused
+ client connections to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="25340"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Windows, an error in <filename>configure.js</filename> caused
+ installation of source distributions to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="DROP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26703"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">DROP DATABASE</literal> failed for attempts
+ to drop databases with names that contained the legacy
+ <literal>#mysql50#</literal> name prefix.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="triggers"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32790"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Incorrect assertions could cause a server crash for
+ <literal role="stmt">DELETE</literal> triggers for transactional
+ tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="UPDATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31747"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For tables with certain definitions,
+ <literal role="stmt">UPDATE</literal> statements could fail to
+ find the correct record to update and report an error when the
+ record did in fact exist.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SHOW PROCESSLIST"/>
+ <manual type="Windows"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30960"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Windows, <literal role="stmt">SHOW PROCESSLIST</literal>
+ could display process entries with a <literal>State</literal>
+ value of <literal>*** DEAD ***</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="FEDERATED"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35509"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ </versions>
+
+ <message>
+
+ <para>
+ There was a memory leak when connecting to a
+ <literal>FEDERATED</literal> table using a connection string
+ that had a host value of <literal>localhost</literal> or omitted
+ the host and a port value of <literal>0</literal> or omitted the
+ port.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CREATE SERVER"/>
+ <manual type="ALTER SERVER"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34790"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">CREATE SERVER</literal> and
+ <literal role="stmt">ALTER SERVER</literal> could crash the
+ server if out-of-memory conditions occurred.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35226"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When using row-based replication, a slave could crash at startup
+ because it received a row-based replication event that
+ <literal>InnoDB</literal> could not handle due to an incorrect
+ test of the query string provided by MySQL, which was
+ <literal>NULL</literal> for row-based replication events.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="FEDERATED"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28269"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>FEDERATED</literal> storage engine did not perform
+ identifier quoting for column names that are reserved words when
+ sending statements to the remote server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql.server"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30378"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An orphaned PID file from a no-longer-running process could
+ cause <command>mysql.server</command> to wait for that process
+ to exit even though it does not exist.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ucs2"/>
+ <manual type="MyISAM"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32705"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Inserting strings with a common prefix into a table that used
+ the <literal>ucs2</literal> character set corrupted the table.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MyISAM"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33222"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal>MyISAM</literal> tables, <literal role="stmt">CHECK
+ TABLE</literal> (non-<literal>QUICK</literal>) and any form of
+ <literal role="stmt">REPAIR TABLE</literal> incorrected treated
+ rows as corrupted under the combination of the following
+ conditions:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The table had dynamic row format
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The table had a <literal role="type">CHAR</literal> (not
+ <literal role="type">VARCHAR</literal>) column longer than
+ 127 bytes (for multi-byte character sets this could be less
+ than 127 characters)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The table had rows with a signifcant length of more than 127
+ bytes significant length in that
+ <literal role="type">CHAR</literal> column (that is, a byte
+ beyond byte position 127 must be a non-space character)
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ This problem affected <literal role="stmt">CHECK
+ TABLE</literal>, <literal role="stmt">REPAIR TABLE</literal>,
+ <literal role="stmt">OPTIMIZE TABLE</literal>,
+ <literal role="stmt">ALTER TABLE</literal>.
+ <literal role="stmt">CHECK TABLE</literal> reported and marked
+ the table as crashed if any row was present that fulfilled the
+ third condition. The other statements deleted these rows.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="plugins"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33358"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="type">ENUM</literal>- or
+ <literal>SET</literal>-valued plugin variables could not be set
+ from the command line.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="INFORMATION_SCHEMA"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34656"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For debug builds, reading from
+ <literal role="is">INFORMATION_SCHEMA.TABLES</literal> or
+ <literal role="is">INFORMATION_SCHEMA.COLUMNS</literal> could
+ cause assertion failures. This could happen under rare
+ circumstances when <literal>INFORMATION_SCHEMA</literal> fails
+ to get information about a table (for example, when a connection
+ is killed).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="34726"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A server running with the <option>--debug</option> option could
+ attempt to dereference a null pointer when opening tables,
+ resulting in a crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="binary log"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30604"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Binary logging for a stored procedure differed depending on
+ whether or not execution occurred in a prepared statement.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="innodb_data_home_dir"/>
+ <manual type="MySQLInstanceConfig.exe"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="6627"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>MySQLInstanceConfig.exe</command> did not save the
+ <literal>innodb_data_home_dir</literal> value to the
+ <filename>my.ini</filename> file under certain circumstances.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="34598"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Dangerous pointer arithmetic crashed the server on some systems.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="FEDERATED"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33946"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For a <literal>FEDERATED</literal> table with an index on a
+ nullable column, accessing the table could crash a server,
+ return an incorrect result set, or return <literal>ERROR 1030
+ (HY000): Got error 1430 from storage engine</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="debugging"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34424"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The per-thread debugging settings stack was not being
+ deallocated before thread termination, resulting in a stack
+ memory leak.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="debug"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34678"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Assigning an <quote>incremental</quote> value to the
+ <literal role="sysvar">debug</literal> system variable did not
+ add the new value to the current value. For example, if the
+ current <literal role="sysvar">debug</literal> value was
+ <literal>'T'</literal>, the statement <literal>SET debug =
+ '+P'</literal> resulted in a value of <literal>'P'</literal>
+ rather than the correct value of <literal>'P:T'</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="plugin_dir"/>
+ <manual type="mysql_config"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31736"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For packages that are built within their own prefix (for
+ example, <filename>/usr/local/mysql</filename>) the plugin
+ directory will be <filename>lib/plugin</filename>. For packages
+ that are built to be installed into a system-wide prefix (such
+ as RPM packages with a prefix of <filename>/usr</filename>), the
+ plugin directory will be <filename>lib/mysql/plugin</filename>
+ to ensure a clean <filename>/usr/lib</filename> hierarchy. In
+ both cases, the <literal>$pkglibdir</literal> configuration
+ setting is used at build time to set the plugin directory.
+ </para>
+
+ <para>
+ The current plugin directory location is available as the value
+ of the <literal>plugin_dir</literal> system variable as before,
+ but the <command>mysql_config</command> script now has a
+ <option>--plugindir</option> option that can be used externally
+ to the server by third-party plugin writers to obtain the
+ default plugin directory pathname and configure their
+ installation directory appropriately.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQLInstanceConfig.exe"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="24215"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If a user installed MySQL Server and set a password for the
+ <literal>root</literal> user, and then uninstalled and
+ reinstalled MySQL Server to the same location, the user could
+ not use the MySQL Instance Config wizard to configure the server
+ because the uninstall operation left the previous data directory
+ intact. The config wizard <emphasis>assumed</emphasis> that any
+ new install (not an upgrade) would have the default data
+ directory where the <literal>root</literal> user has no
+ password. The installer now writes a registry key named
+ <literal>FoundExistingDataDir</literal>. If the installer finds
+ an existing data directory, the key will have a value of 1,
+ otherwise it will have a value of 0. When
+ <command>MySQLInstanceConfig.exe</command> is run, it will
+ attempt to read the key. If it can read the key, and the value
+ is 1 and there is no existing instance of the server (indicating
+ a new installation), the Config Wizard will allow the user to
+ input the old password so the server can be configured.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqldump"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="25162"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <command>mysqldump</command> in MySQL 5.1 resulted in dump
+ files that could not be loaded in MySQL 5.0 because
+ <literal>USING <replaceable>type_name</replaceable></literal>
+ options in index definitions appeared after the index column
+ list, whereas 5.0 accepted only the old syntax that has
+ <literal>USING</literal> before the column list. The parser in
+ 5.0 now accepts <literal>USING</literal> following the column
+ list.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqldump"/>
+ <manual type="character_set_results"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34192"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqldump</command> attempts to set the
+ <literal role="sysvar">character_set_results</literal> system
+ variable after connecting to the server. This failed for pre-4.1
+ servers that have no such variable, but
+ <command>mysqldump</command> did not account for this and 1)
+ failed to dump database contents; 2) failed to produce any error
+ message alerting the user to the problem.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="key_buffer_size"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35272"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Memory-allocation failures for attempts to set
+ <literal role="sysvar">key_buffer_size</literal> to large values
+ could result in a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="securityfix"/>
+ <manual type="LOAD DATA LOCAL INFILE"/>
+ <manual type="FETCH LOCAL FILE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29605"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A client that connects to a malicious server could be tricked by
+ the server into sending files from the client host to the
+ server. This occurs because the
+ <literal>libmysqlclient</literal> client library would respond
+ to a <literal>FETCH LOCAL FILE</literal> request from the server
+ even if the request is sent for statements from the client other
+ than <literal>LOAD DATA LOCAL INFILE</literal>. The client
+ library has been modified to respond to a <literal>FETCH LOCAL
+ FILE</literal> request from the server only if is is sent in
+ response to a <literal>LOAD DATA LOCAL INFILE</literal>
+ statement from the client.
+ </para>
+
+ <para>
+ The client library now also checks whether
+ <literal>CLIENT_LOCAL_FILE</literal> is set and refuses to send
+ a local file if not.
+ </para>
+
+ <note>
+ <para>
+ Binary distributions ship with the
+ <literal>local-infile</literal> capability enabled.
+ Applications that do not use this functionality should disable
+ it to be safe.
+ </para>
+ </note>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="InnoDB monitors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34053"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="priv">PROCESS</literal> privilege now is
+ required to start or stop the <literal>InnoDB</literal> monitor
+ tables (see linkend="innodb-monitor"/>). Previously, no
+ privilege was required.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="report_host"/>
+ <manual type="report_password"/>
+ <manual type="report_port"/>
+ <manual type="report_user"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The new read-only global system variables
+ <literal>report_host</literal>,
+ <literal>report_password</literal>,
+ <literal>report_port</literal>, and
+ <literal>report_user</literal> system variables provide runtime
+ access to the values of the corresponding
+ <option>--report-host</option>,
+ <option>--report-password</option>,
+ <option>--report-port</option>, and
+ <option>--report-user</option> options.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="views"/>
+ <manual type="metadata"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30217"/>
+ <seealsobug bugid="11986"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ View metadata returned from
+ <literal role="is">INFORMATION_SCHEMA.VIEWS</literal> was
+ changed by the fix for Bug#11986, causing the information
+ returned in MySQL 5.1 to differ from that returned in 5.0.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33033"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The new index condition pushdown optimization could cause a
+ server crash when used with the range access method over an
+ <literal>InnoDB</literal> table.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30221"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For multi-read-range scans used to resolve
+ <literal>LIMIT</literal> queries, failure to close the scan
+ caused file descriptor leaks for <literal>MyISAM</literal>
+ tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="stored procedures"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="15192"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Stored procedure exception handlers were catching fatal errors
+ (such as out of memory errors), which could cause execution not
+ to stop to due a continue handler. Now fatal errors are not
+ caught by exception handlers and a fatal error is returned to
+ the client.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Threads_connected"/>
+ <manual type="Threads_created"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="17954"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Delayed-insert threads were counted as connected but not as
+ created, incorrectly leading to a
+ <literal>Threads_connected</literal> value greater than the
+ <literal>Threads_created</literal> value.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="general_log_file"/>
+ <manual type="slow_query_log_file"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32748"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Assignment of relative pathnames to
+ <literal role="sysvar">general_log_file</literal> or
+ <literal>slow_query_log_file</literal> did not always work.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="events"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32771"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ There was a race condition between the event scheduler and the
+ server shutdown thread.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="log_output"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34820"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="sysvar">log_output</literal> system variable
+ could be set to an illegal value.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="FLUSH TABLES"/>
+ <manual type="SHOW FUNCTION STATUS"/>
+ <manual type="SHOW PROCEDURE STATUS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34895"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Concurrent execution of
+ <literal role="stmt" condition="flush">FLUSH TABLES</literal>
+ along with <literal role="stmt">SHOW FUNCTION STATUS</literal>
+ or <literal role="stmt">SHOW PROCEDURE STATUS</literal> could
+ cause a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="INFORMATION_SCHEMA"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35096"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Access-denied messages for <literal>INFORMATION_SCHEMA</literal>
+ incorrectly showed the name of the default database instead.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="INFORMATION_SCHEMA"/>
+ <manual type="SELECT"/>
+ <manual type="privileges"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35955"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If a <literal role="stmt">SELECT</literal> table list contained
+ at least one <literal>INFORMATION_SCHEMA</literal> table, the
+ required privileges for accessing the other tables were reduced.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MyISAM"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35733"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An incorrect error and message was produced for attempts to
+ create a <literal>MyISAM</literal> table with an index
+ (<filename>.MYI</filename>) filename that was already in use by
+ some other <literal>MyISAM</literal> table that was open at the
+ same time. For example, this might happen if you use the same
+ value of the <literal>INDEX DIRECTORY</literal> table option for
+ tables belonging to different databases.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqlhotcopy"/>
+ <manual type="--record_log_pos"/>
+ <manual type="Master_Log_File"/>
+ <manual type="Read_Master_Log_Pos"/>
+ <manual type="Relay_Master_Log_File"/>
+ <manual type="Exec_Master_Log_Pos"/>
+ <manual type="SHOW SLAVE STATUS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27101"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For the <option>--record_log_pos</option> option,
+ <command>mysqlhotcopy</command> now determines the slave status
+ information from the result of <literal role="stmt">SHOW SLAVE
+ STATUS</literal> by using the
+ <literal>Relay_Master_Log_File</literal> and
+ <literal>Exec_Master_Log_Pos</literal> values rather than the
+ <literal>Master_Log_File</literal> and
+ <literal>Read_Master_Log_Pos</literal> values. This provides a
+ more accurate indication of slave execution relative to the
+ master.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CREATE SERVER"/>
+ <manual type="DROP SERVER"/>
+ <manual type="FLUSH PRIVILEGES"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34789"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">DROP SERVER</literal> does not release
+ memory cached for server structures created by
+ <literal role="stmt">CREATE SERVER</literal>, so repeated
+ iterations of these statements resulted in a memory leak.
+ <literal role="stmt" condition="flush">FLUSH
+ PRIVILEGES</literal> now releases the memory allocated for
+ <literal role="stmt">CREATE SERVER</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="--help"/>
+ <manual type="option processing"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35224"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For boolean options, the option-processing library now prints
+ additional information in the <option>--help</option> message:
+ If the option is enabled by default, the message says so and
+ indicates that the <option>--skip</option> form of the option
+ disables the option. This affects all compiled MySQL programs
+ that use the library.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="GET_LOCK()"/>
+ <manual type="SLEEP()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="10374"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If a connection was waiting for a
+ <literal role="func">GET_LOCK()</literal> lock or a
+ <literal role="func">SLEEP()</literal> call, and the connection
+ aborted, the server did not detect this and thus did not close
+ the connection. This caused a waste of system resources
+ allocated to dead connections. Now the server checks such a
+ connection every five seconds to see whether it has been
+ aborted. If so, the connection is killed (and any lock request
+ is aborted).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SELECT"/>
+ <manual type="INTO"/>
+ <manual type="subqueries"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30105"/>
+ <fixes bugid="33204"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The parser accepted an <literal>INTO</literal> clause in nested
+ <literal role="stmt">SELECT</literal> statements, which is
+ invalid because such statements must return their results to the
+ outer context.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="3353"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">RESTORE</literal> failed for databases or
+ tables with names that contain certain non-alphanumeric
+ characters, such as spaces.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ <manual type="semi-join"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33062"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Repeatedly executing a query with a semi-join subquery could
+ cause a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql_stmt_prepare()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36004"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="cfunc">mysql_stmt_prepare()</literal> did not
+ reset the list of messages (those messages available via
+ <literal role="stmt">SHOW WARNINGS</literal>).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="innodb_log_arch_dir"/>
+ </tags>
+
+ <versions>
+ <version ver="5.0.24"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>innodb_log_arch_dir</literal> system variable
+ (which has been unused since MySQL 4.0.6) is now deprecated and
+ should no longer be used. It will be removed in MySQL 5.1.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="innodb_log_arch_dir"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.21"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>innodb_log_arch_dir</literal> system variable
+ (which has been deprecated since MySQL 5.0.24) has been removed
+ and should no longer be used.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="stored routines"/>
+ <manual type="Questions"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="24289"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>Questions</literal> status variable is intended as
+ a count of statements sent by clients to the server, but was
+ also counting statements executed within stored routines.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="bison"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34926"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some binaries produced stack corruption messages due to being
+ built with versions of <command>bison</command> older than 2.1.
+ Builds are now created using <command>bison</command> 2.3.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28680"/>
+ <fixes bugid="32797"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>mysql.servers</literal> table was not created
+ during installation on Windows.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="Vista"/>
+ <manual type="JScript"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36103"/>
+ </bugs>
+
+ <versions>
+ <version ver="4.1.25"/>
+ <version ver="5.0.51b"/>
+ <version ver="5.0.60"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Windows, the installer attempted to use JScript to determine
+ whether the target data directory already existed. On Windows
+ Vista x64, this resulted in an error because the installer was
+ attempting to run the JScript in a 32-bit engine, which wasn't
+ registered on Vista. The installer no longer uses JScript but
+ instead relies on a native WiX command.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="innodb_buffer_pool_awe_mem_mb"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.13"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>innodb_buffer_pool_awe_mem_mb</literal> system
+ variable has been removed and should no longer be used.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <highlight type="replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33055"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When updating columns for a row when using a
+ <literal>Falcon</literal> table, the values for columns that
+ were not updated were replicated as <literal>NULL</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34174"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal>Falcon</literal>, under some circumstances, a
+ rolled back record could appear not to be removed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="isolation level"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34164"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Attempting to set the isolation level to a value not supported
+ by <literal>Falcon</literal> caused a <literal>Falcon</literal>
+ assertion failure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33634"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Contention between concurrent <literal>Falcon</literal>
+ transactions could cause some queries to be starved for a long
+ time.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33175"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Inserting millions of rows into a <literal>Falcon</literal>
+ table could cause the insert operation to hang.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="privileges"/>
+ <manual type="CHECK TABLE"/>
+ <manual type="CHECKSUM TABLE"/>
+ <manual type="CREATE TABLE ... LIKE"/>
+ <manual type="SHOW COLUMNS"/>
+ <manual type="SHOW CREATE TABLE"/>
+ <manual type="SHOW CREATE VIEW"/>
+ <manual type="SHOW INDEX"/>
+ <manual type="SHOW OPEN TABLES"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27145"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Access privileges for several statements are more accurately
+ checked:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal role="stmt">CHECK TABLE</literal> requires some
+ privilege for the table.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal role="stmt">CHECKSUM TABLE</literal> requires
+ <literal role="priv">SELECT</literal> for the table.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>CREATE TABLE ... LIKE</literal> requires
+ <literal role="priv">SELECT</literal> for the source table
+ and <literal role="priv">CREATE</literal> for the
+ destination table.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal role="stmt">SHOW COLUMNS</literal> displays
+ information only for those columns you have some privilege
+ for.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal role="stmt">SHOW CREATE TABLE</literal> requires
+ some privilege for the table (previously required
+ <literal role="priv">SELECT</literal>).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal role="stmt">SHOW CREATE VIEW</literal> requires
+ <literal role="priv">SHOW VIEW</literal> and
+ <literal role="priv">SELECT</literal> for the view.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal role="stmt">SHOW INDEX</literal> requires some
+ privilege for any column.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal role="stmt">SHOW OPEN TABLES</literal> displays
+ only tables for which you have some privilege on any table
+ column.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <highlight type="partitioning"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33480"/>
+ <fixes bugid="33735"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Multiple simultaneous inserts into a partitioned
+ <literal>Falcon</literal> table could deadlock.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="Falcon"/>
+ <manual type="falcon_lock_timeout"/>
+ <manual type="falcon_lock_wait_timeout"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33474"/>
+ <fixes bugid="33072"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>falcon_lock_timeout</literal> system variable,
+ which had a value in milliseconds, has been replaced with
+ <literal>falcon_lock_wait_timeout</literal>, which has a value
+ in seconds. The default value of
+ <literal>falcon_lock_wait_timeout</literal> is 50 seconds. This
+ has been done for better name and unit consistency with the
+ <literal>innodb_lock_wait_timeout</literal> system variable.
+ Uses of the old variable should be converted to use the new
+ variable.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33191"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Multiple concurrent delete operations on a
+ <literal>Falcon</literal> table were serialized rather than
+ executing concurrently, resulting in poor performance.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33080"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Multiple <literal>Falcon</literal> gopher threads attempting to
+ update the same index could result in failure to add new index
+ entries.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="DROP TABLESPACE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33216"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The error message was vague for attempts to drop a
+ <literal>Falcon</literal> tablespace that contained tables. Now
+ the message <errortext>Tablespace busy</errortext> is returned.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33492"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ After a server restart, <literal>Falcon</literal> mishandled
+ metadata, resulting in apparent corruption of
+ <literal role="type">BLOB</literal> data.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33068"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Falcon</literal> tried to delete a record from an empty
+ record locator page, which could cause a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32620"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Falcon</literal> did not properly handle quoted column
+ name or tablespace name identifiers.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="TRUNCATE TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32730"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Concurrent <literal role="stmt" condition="truncate">TRUNCATE
+ TABLE</literal> operations for <literal>Falcon</literal> tables
+ caused <literal>Falcon</literal> to crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="Mac OS X"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32201"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Mac OS X, creating a <literal>Falcon</literal> table using a
+ new <literal>Falcon</literal> installation caused a crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31286"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Falcon</literal> could crash when the maximum record
+ size was exceeded.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="falcon_consistent_read"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34331"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Setting <literal>falcon_consistent_read</literal> to a value of
+ 1 or <literal>ON</literal> resulted in a value of −1 being
+ assigned.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="INFORMATION_SCHEMA"/>
+ <manual type="FALCON_TRANSACTIONS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34241"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>INFORMATION_SCHEMA.FALCON_TRANSACTIONS</literal>
+ had two columns named <literal>STATE</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="Mac OS X"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34095"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Falcon</literal> did not compile on Mac OS X/Intel or
+ Mac OS X/PPC.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33759"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal>Falcon</literal>, an initializing transaction
+ created a dependency on a commitNoUpdate transaction releasing
+ transaction dependencies, which caused an assertion failure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33657"/>
+ <fixes bugid="33667"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For table creation, <literal>Falcon</literal> did not handle
+ identifiers with embedded double quotes.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="DELETE"/>
+ <highlight type="replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32150"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>DELETE FROM
+ <replaceable>tbl_name</replaceable></literal> (no
+ <literal>WHERE</literal> clause) for a <literal>Falcon</literal>
+ table caused replication to fail on the slave.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32921"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Falcon</literal> failed to rebuild a Section page
+ during recovery, causing a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33608"/>
+ <fixes bugid="33665"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Incomplete <literal>Falcon</literal> recovery after server
+ restarts eventually resulted in tablespace corruption.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="init_time"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26294"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.62"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The internal <function>init_time()</function> library function
+ was renamed to <function>my_init_time()</function> to avoid
+ conflicts with external libraries.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Solaris"/>
+ <manual type="ARCHIVE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34094"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Compilation failed on Solaris for the <literal>ARCHIVE</literal>
+ storage engine due to inclusion of <filename>getopt.h</filename>
+ in the <literal>ARCHIVE</literal> code.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqltest"/>
+ <manual type="replace_result"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36041"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqltest</command> was performing escape processing
+ for the <option>--replace_result</option> command, which it
+ should not have been.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqltest"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36465"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.62"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqltest</command> ignored the value of
+ <option>--tmpdir</option> in one place.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysql_upgrade"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36469"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.62"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql_upgrade</command> now has a
+ <option>--tmpdir</option> option to enable the location of
+ temporary files to be specified.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="FLOAT"/>
+ <manual type="ZEROFILL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36139"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.62"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Conversion of a <literal>FLOAT ZEROFILL</literal> value to
+ string could cause a server crash if the value was
+ <literal>NULL</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="event scheduler"/>
+ <manual type="mysql_upgrade"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35824"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql_upgrade</command> did not properly update the
+ <literal>mysql.event</literal> table.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="parser"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="15776"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.62"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The parser used signed rather than unsigned values in some cases
+ that caused legal lengths in column declarations to be rejected.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <manual type="FEDERATED"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.24"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>FEDERATED</literal> storage engine is not included
+ in binary distributions of MySQL 5.1.24. (It will be included
+ again in 5.1.25.)
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="innodb_log_archive"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.18"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>innodb_log_archive</literal> system variable has
+ been removed. The impact of this change should be low because
+ the variable was unused, anyway.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MERGE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36006"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>MERGE</literal> storage engine did a table scan for
+ <literal>SELECT COUNT(*)</literal> statements when it could
+ calculate the number of records from the underlying tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36005"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.62"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server crashed inside <literal>NOT IN</literal> subqueries
+ with an impossible <literal>WHERE</literal> or
+ <literal>HAVING</literal> clause, such as <literal>NOT IN
+ (SELECT ... FROM t1, t2, ... WHERE 0)</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="GROUP BY"/>
+ <manual type="ORDER BY"/>
+ <manual type="gbk"/>
+ <manual type="big5"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35993"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.62"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Grouping or ordering of long values in unindexed
+ <literal role="type">BLOB</literal> or
+ <literal role="type">TEXT</literal> columns with the
+ <literal>gbk</literal> or <literal>big5</literal> character set
+ crashed the server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="read_only"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35732"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.24-ndb-6.3.13"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Enabling the <literal>read_only</literal> system variable while
+ autocommit mode was enabled caused
+ <literal role="stmt">SELECT</literal> statements for
+ transactional storage engines to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="36023"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.62"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An error in calculation of the precision of zero-length items
+ (such as <literal>NULL</literal>) caused a server crash for
+ queries that employed temporary tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="configuration"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34291"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.62"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Several additional configuration scripts in the
+ <filename>BUILD</filename> directory now are included in source
+ distributions. These may be useful for users who wish to build
+ MySQL from source. (See
+ <xref linkend="installing-source-tree"/>, for information about
+ what they do.)
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="debugging"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35986"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.62"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>SET GLOBAL debug=''</literal> resulted in a Valgrind
+ warning in <function>DbugParse()</function>, which was reading
+ beyond the end of the control string.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="35298"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.62"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The combination of
+ <literal role="func">GROUP_CONCAT()</literal>,
+ <literal>DISTINCT</literal>, and <literal>LEFT JOIN</literal>
+ could crash the server when the right table is empty.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35844"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server ignored any covering index used for
+ <literal>ref</literal> access of a table in a query with
+ <literal>ORDER BY</literal> if this index was incompatible with
+ the <literal>ORDER BY</literal> list and there was another
+ covering index compatible with this list. As a result,
+ suboptimal execution plans were chosen for some queries that
+ used an <literal>ORDER BY</literal> clause.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34297"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Windows 64-bit builds, an apparent compiler bug caused memory
+ overruns for code in <filename>innobase/mem/*</filename>.
+ Removed optimizations so as not to trigger this problem.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="event scheduler"/>
+ <manual type="libmysqld"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35997"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The Event Scheduler was not designed to work under the embedded
+ server. It is now disabled for the embedded server, and the
+ <literal role="sysvar">event_scheduler</literal> system variable
+ is not displayed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="tests"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28563"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>jp</literal> test suite was not working.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="UPDATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36676"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.64"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Multiple-table <literal role="stmt">UPDATE</literal> statements
+ that used a temporary table could fail to update all qualifying
+ rows or fail with a spurious duplicate-key error.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="REGEXP"/>
+ <manual type="CONCAT()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36488"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.64"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A <literal role="op">REGEXP</literal> match could return
+ incorrect rows when the previous row matched the expression and
+ used <literal role="func">CONCAT()</literal> with an empty
+ string.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="EXPLAIN"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36011"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.64"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal>EXPLAIN EXTENDED</literal>, execution of an
+ uncorrelated <literal>IN</literal> subquery caused a crash if
+ the subquery required a temporary table for its execution.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="key_buffer_size"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36705"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.64"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Windows 64-bit systems, temporary variables of
+ <literal>long</literal> types were used to store
+ <literal>ulong</literal> values, causing key cache
+ initialization to receive distorted parameters. The effect was
+ that setting <literal role="sysvar">key_buffer_size</literal> to
+ values of 2GB or more caused memory exhaustion to due allocation
+ of too much memory.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="installation"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36305"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When updating an existing instance (for example, from MySQL 5.0
+ to 5.1, or 5.1 to 6.0), the Instance Configuration Wizard
+ unnecessarily prompted for a <literal>root</literal> password
+ when there was an existing <literal>root</literal> password.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <manual type="CHECK TABLE"/>
+ <manual type="FOR UPGRADE"/>
+ <manual type="REPAIR TABLE"/>
+ <manual type="USE_FRM"/>
+ <manual type="mysqlcheck"/>
+ <manual type="mysql_upgrade"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36055"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.62"/>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some changes were made to <literal>CHECK TABLE ... FOR
+ UPGRADE</literal> and <literal role="stmt">REPAIR
+ TABLE</literal> with respect to detection and handling of tables
+ with incompatible <filename>.frm</filename> files (files created
+ with a different version of the MySQL server). These changes
+ also affect <command>mysqlcheck</command> because that program
+ uses <literal role="stmt">CHECK TABLE</literal> and
+ <literal>REPAIR</literal> table, and thus also
+ <command>mysql_upgrade</command> because that program invokes
+ <command>mysqlcheck</command>.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ If your table was created by a different version of the
+ MySQL server than the one you are currently running,
+ <literal>CHECK TABLE ... FOR UPGRADE</literal> indicates
+ that the table has an <filename>.frm</filename> file with an
+ incompatible version. In this case, the result set returned
+ by <literal role="stmt">CHECK TABLE</literal> contains a
+ line with a <literal>Msg_type</literal> value of
+ <literal>error</literal> and a <literal>Msg_text</literal>
+ value of <literal>Table upgrade required. Please do "REPAIR
+ TABLE `<replaceable>tbl_name</replaceable>`" to fix
+ it!</literal>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal role="stmt">REPAIR TABLE</literal> without
+ <literal>USE_FRM</literal> upgrades the
+ <filename>.frm</filename> file to the current version.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If you use <literal>REPAIR TABLE ...USE_FRM</literal> and
+ your table was created by a different version of the MySQL
+ server than the one you are currently running,
+ <literal role="stmt">REPAIR TABLE</literal> will not attempt
+ to repair the table. In this case, the result set returned
+ by <literal role="stmt">REPAIR TABLE</literal> contains a
+ line with a <literal>Msg_type</literal> value of
+ <literal>error</literal> and a <literal>Msg_text</literal>
+ value of <literal>Failed repairing incompatible .FRM
+ file</literal>.
+ </para>
+ <para>
+ Previously, use of <literal>REPAIR TABLE
+ ...USE_FRM</literal> with a table created by a different
+ version of the MySQL server risked the loss of all rows in
+ the table.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="configure"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35011"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The (undocumented) <command>configure</command> script
+ previously included with binary distributions is no longer
+ included.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqldumpslow"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="20455"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqldumpslow</command> returned a confusing error
+ message when no configuration file was found.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="SHOW COLUMN TYPES"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="5299"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The undocumented, deprecated, and not useful <literal>SHOW
+ COLUMN TYPES</literal> statement has been removed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32680"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Deeply nested subqueries could cause stack overflow or a server
+ crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="debugging"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35104"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Debugging symbols were missing for some executables in Windows
+ binary distributions.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35850"/>
+ <seealsobug bugid="26447"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <quote>prefer full scan on clustered primary key over full
+ scan of any secondary key</quote> optimizer rule introduced by
+ Bug#26447 caused a performance regression for some queries, so
+ it has been disabled.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="parser"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36320"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server crashed while parsing large floating-point numbers
+ such as <literal>1e37</literal> or <literal>-1e15</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36457"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>ER_TRUNCATED_WRONG_VALUE</literal> warning
+ condition was sometimes raised as an error.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35936"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some syntactically invalid statements could cause the server to
+ return an error message containing garbage characters.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36137"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The combination of semi-join and materialization both being
+ enabled could lead to assertion failure during subquery
+ processing.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36133"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Range optimizer evaluation of <literal>IN</literal> subqueries
+ to be handled with the materialization strategy could lead to
+ assertion failure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36128"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A server crash could occur during the cleanup phase of subquery
+ execution.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35767"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Processing of an uncorrelated subquery using semi-join could
+ cause incorrect results or a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35674"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The range optimizer ignored conditions on inner tables in
+ semi-join <literal>IN</literal> subqueries, causing the
+ optimizer to miss good query execution plans.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35550"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A semi-join subquery in the <literal>ON</literal> clause in the
+ absence of a <literal>WHERE</literal> clause caused a server
+ crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35160"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The table pullout strategy was not reflected in <literal>EXPLAIN
+ EXTENDED</literal> output if not all of the subquery tables were
+ pulled out.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34799"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A server crash or memory overrun could occur with a dependent
+ subquery and joins.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33509"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Use of 61 nested subqueries caused a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CHECKSUM TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35570"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Different invocations of <literal role="stmt">CHECKSUM
+ TABLE</literal> could return different results for a table
+ containing columns with spatial data types.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ORDER BY"/>
+ <manual type="CHAR()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34949"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Passing an invalid parameter to
+ <literal role="func">CHAR()</literal> in an <literal>ORDER
+ BY</literal> clause caused the server to hang.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="prepared statements"/>
+ <manual type="PREPARE"/>
+ <manual type="mysql_stmt_prepare()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27420"/>
+ <fixes bugid="27430"/>
+ <fixes bugid="27690"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A change has been made to the way that the server handles
+ prepared statements. This affects prepared statements processed
+ at the SQL level (using the
+ <literal role="stmt" condition="sql-syntax-prepared-statements">PREPARE</literal>
+ statement) and those processed using the binary client-server
+ protocol (using the
+ <literal role="cfunc">mysql_stmt_prepare()</literal> C API
+ function).
+ </para>
+
+ <para>
+ Previously, changes to metadata of tables or views referred to
+ in a prepared statement could cause a server crash when the
+ statement was next executed, or perhaps an error at execute time
+ with a crash occurring later. For example, this could happen
+ after dropping a table and recreating it with a different
+ definition.
+ </para>
+
+ <para>
+ Now metadata changes to tables or views referred to by prepared
+ statements are detected and cause automatic repreparation of the
+ statement when it is next executed. Metadata changes occur for
+ DDL statements such as those that create, drop, alter, rename,
+ or truncate tables, or that analyze, optimize, or repair tables.
+ Repreparation also occurs after referenced tables or views are
+ flushed from the table definition cache, either implicitly to
+ make room for new entries in the cache, or explicitly due to
+ <literal role="stmt" condition="flush">FLUSH TABLES</literal>.
+ </para>
+
+ <para>
+ Repreparation is automatic, but to the extent that it occurs,
+ performance of prepared statements is diminished.
+ </para>
+
+ <para>
+ Table content changes (for example, with
+ <literal role="stmt">INSERT</literal> or
+ <literal role="stmt">UPDATE</literal>) do not cause
+ repreparation, nor do <literal role="stmt">SELECT</literal>
+ statements.
+ </para>
+
+ <para>
+ An incompatibility with previous versions of MySQL is that a
+ prepared statement may now return a different set of columns or
+ different column types from one execution to the next. For
+ example, if the prepared statement is <literal>SELECT * FROM
+ t1</literal>, altering <literal>t1</literal> to contain a
+ different number of columns causes the next execution to return
+ a number of columns different from the previous execution.
+ </para>
+
+ <para>
+ Older versions of the client library cannot handle this change
+ in behavior. For applications that use prepared statements with
+ the new server, an upgrade to the new client library is strongly
+ recommended.
+ </para>
+
+ <para>
+ Along with this change to statement repreparation, the default
+ value of the <literal>table_definition_cache</literal> system
+ variable has been increased from 128 to 256. The purpose of this
+ increase is to lessen the chance that prepared statements will
+ need repreparation due to referred-to tables/views having been
+ flushed from the cache to make room for new entries.
+ </para>
+
+ <para>
+ A new status variable, <literal>Com_stmt_reprepare</literal>,
+ has been introduced to track the number of repreparations.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33743"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A number of problems in new subquery optimization code meant
+ that MySQL could pick an incorrect query plan when using
+ InsideOut and/or FirstMatch subquery optimizations, which in
+ turn would cause wrong query results.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <highlight type="importantchange"/>
+ <manual type="FEDERATED"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37069"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.64"/>
+ <version ver="5.1.26"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message ver="5.0.64">
+
+ <para>
+ The <literal>FEDERATED</literal> storage engine is now disabled
+ by default in the <filename>.cnf</filename> files shipped with
+ MySQL distributions (<filename>my-huge.cnf</filename>,
+ <filename>my-medium.cnf</filename>, and so forth). This affects
+ server behavior only if you install one of these files.
+ </para>
+
+ </message>
+
+ <message ver="5.1.26,6.0.6">
+
+ <para>
+ The <literal>FEDERATED</literal> storage engine is now disabled
+ by default in binary distributions. The engine is still
+ available and can be enabled by starting the server with the
+ <option>--federated</option> option.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="privileges"/>
+ <manual type="GRANT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="16470"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Use of <literal role="stmt">GRANT</literal> statements with
+ grant tables from an old version of MySQL could cause a server
+ crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36434"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.26"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <filename>ha_innodb.so</filename> was incorrectly installed in
+ the <filename>lib/mysql</filename> directory rather than in
+ <filename>lib/mysql/plugin</filename>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="TRUNCATE TABLE"/>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29507"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt" condition="truncate">TRUNCATE
+ TABLE</literal> for <literal>InnoDB</literal> tables returned a
+ count showing too many rows affected. Now the statement returns
+ 0 for <literal>InnoDB</literal> tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="Handler_delete"/>
+ <manual type="Handler_update"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35537"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>InnoDB</literal> was not updating the
+ <literal>Handler_delete</literal> or
+ <literal>Handler_update</literal> status variables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="CREATE INDEX"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36169"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">CREATE INDEX</literal> for
+ <literal>InnoDB</literal> tables could under very rare
+ circumstances cause the server to crash..
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36278"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal>InnoDB</literal> tables, the
+ <literal>DATA_FREE</literal> column of the
+ <literal role="is">INFORMATION_SCHEMA.TABLES</literal> displayed
+ free space in kilobytes rather than bytes. Now it displays
+ bytes.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="CHAR"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37426"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.26"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Row-based replication broke for <literal>utf8</literal>
+ <literal role="type">CHAR</literal> columns longer than 85
+ characters.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37004"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.26"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>NOT IN</literal> subqueries that selected
+ <literal role="func">MIN()</literal> or
+ <literal role="func">MAX()</literal> values but produced an
+ empty result could cause a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33812"/>
+ <seealsobug bugid="38158"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.66"/>
+ <version ver="5.1.26"/>
+ </versions>
+
+ <message ver="5.0.66">
+
+ <para>
+ The <command>mysql</command> client incorrectly parsed
+ statements containing the word <quote>delimiter</quote> in
+ mid-statement.
+ </para>
+
+ <para>
+ The fix for this bug had the side effect of causing the problem
+ reported in Bug#38158, so it was reverted in MySQL 5.0.67.
+ </para>
+
+ </message>
+
+ <message ver="5.1.26">
+
+ <para>
+ The <command>mysql</command> client incorrectly parsed
+ statements containing the word <quote>delimiter</quote> in
+ mid-statement.
+ </para>
+
+ <para>
+ The fix for this bug had the side effect of causing the problem
+ reported in Bug#38158, so it was reverted in MySQL 5.1.27.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38158"/>
+ <seealsobug bugid="33812"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.67"/>
+ <version ver="5.1.27"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The fix for Bug#33812 had the side effect of causing the
+ <command>mysql</command> client not to be able to read some dump
+ files produced with <command>mysqldump</command>. To address
+ this, that fix was reverted.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35480"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.66"/>
+ <version ver="5.1.26"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The code for detecting a byte order mark (BOM) caused
+ <command>mysql</command> to crash for empty input.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="bit-string values"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35658"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.66"/>
+ <version ver="5.1.26"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An empty bit-string literal (<literal>b''</literal>) caused a
+ server crash. Now the value is parsed as an empty bit value
+ (which is treated as an empty string in string context or 0 in
+ numeric context).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32140"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Killing a statement that invoked a stored function could return
+ an incorrect error message indicating table corruption rather
+ than that the statement had been interrupted.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31881"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Occurrence of an error within a stored routine did not always
+ cause immediate statement termination.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36265"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">BACKUP DATABASE</literal> failed to back up
+ views that depend on tables in a different database.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36244"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.66"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <command>mysql</command> client failed to recognize comment
+ lines consisting of <literal>--</literal> followed by a newline.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="parser"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26030"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In some cases, the parser interpreted the <literal>;</literal>
+ character as the end of input and misinterpreted stored program
+ definitions.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36793"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If the length of a field was 3, internal
+ <literal>InnoDB</literal> to integer type conversion didn't work
+ on big-endian machines in the
+ <function>row_search_autoinc_column()</function> function.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36149"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A read past the end of the string could occur while parsing the
+ value of the <option>--innodb-data-file-path</option> option.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="locking"/>
+ <manual type="logging"/>
+ <manual type="binary log"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="25144"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Statements to create, alter, or drop a view were not waiting for
+ completion of statements that were using the view, which led to
+ incorrect sequences of statements in the binary log when
+ statement-based logging was enabled.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="Innodb_row_lock_time_max"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36819"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The code for the <function>ut_usectime()</function> function in
+ <literal>InnoDB</literal> did not handle errors from the
+ <function>gettimeofday()</function> system call. Now it retries
+ <function>gettimeofday()</function> several times and updates
+ the value of the <literal>Innodb_row_lock_time_max</literal>
+ status variable only if <function>ut_usectime()</function> was
+ successful.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="views"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33245"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Selecting from a view that referenced the same table in the
+ <literal>FROM</literal> clause and an <literal>IN</literal>
+ clause caused a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="configure"/>
+ <manual type="without-server"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32898"/>
+ <seealsobug bugid="23973"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.67"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server was built even when <command>configure</command> was
+ run with the <option>--without-server</option> option.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="my.cnf"/>
+ <manual type="option files"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38180"/>
+ <seealsobug bugid="20748"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.66a"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The fix for Bug#20748 caused a problem such that on Unix, MySQL
+ programs looked for options in <filename>~/my.cnf</filename>
+ rather than the standard location of
+ <filename>~/.my.cnf</filename>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="INFORMATION_SCHEMA"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34529"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.60"/>
+ <version ver="5.1.24"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A server crash could occur if
+ <literal>INFORMATION_SCHEMA</literal> tables built in memory
+ were swapped out to disk during query execution.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="UNION"/>
+ <manual type="ORDER BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27848"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An <literal>ORDER BY</literal> at the end of a
+ <literal>UNION</literal> affected individual
+ <literal role="stmt">SELECT</literal> statements rather than the
+ overall query result.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="utf8_general_ci"/>
+ <manual type="Unicode"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="25420"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message ver="6.0.6">
+
+ <para>
+ Certain characters were sorted incorrectly for the following
+ collations: TILDE and GRAVE ACCENT in
+ <literal>big5_chinese_ci</literal>; LATIN SMALL LETTER J in
+ <literal>cp866_general_ci</literal>; TILDE in
+ <literal>gb2312_chinese_ci</literal>; and TILDE in
+ <literal>gbk_chinese_ci</literal>.
+ </para>
+
+ <para>
+ As a result of this fix, any indexes on columns that use these
+ collations and contain the affected characters must be rebuilt
+ when upgrading to 6.0.6 or higher. To do this, use
+ <literal role="stmt">ALTER TABLE</literal> to drop and re-add
+ the indexes, or <command>mysqldump</command> to dump the
+ affected tables and <command>mysql</command> to reload the dump
+ file.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="character sets"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32394"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Conversion of binary values to multi-byte character sets could
+ fail to left-pad values to the correct length. This could result
+ in a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34858"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Logging to the progress tables used by
+ <literal role="stmt">BACKUP DATABASE</literal> and
+ <literal role="stmt">RESTORE</literal> caused a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="37623"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.66"/>
+ <version ver="5.1.26"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some binary distributions had a duplicate <quote>-64bit</quote>
+ suffix in the filename.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38045"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>MyISAM</literal> tables with non-ASCII characters in
+ their names could not be backed up because the
+ <literal>MyISAM</literal> native backup driver did not handle
+ them properly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37654"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal role="stmt">BACKUP DATABASE</literal>, if the
+ <literal>WITH COMPRESSION</literal> clause was not used, an
+ uninitialized variable could cause unpredictable results.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">BACKUP DATABASE</literal> now has a
+ <literal>WITH COMPRESSION</literal> clause. This causes the
+ image file to be compressed, which reduces its size. Compression
+ also may result in improved backup time by reducing writes to
+ disk.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="parser"/>
+ <manual type="syntax"/>
+ <manual type="stored programs"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35577"/>
+ <fixes bugid="37269"/>
+ <fixes bugid="37228"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Freeing of an internal parser stack during parsing of complex
+ stored programs caused a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysqldump"/>
+ <manual type="FLUSH TABLES"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35157"/>
+ <seealsobug bugid="38303"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.25"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqldump</command> now adds the
+ <literal>LOCAL</literal> qualifier to the
+ <literal role="stmt" condition="flush">FLUSH TABLES</literal>
+ statement that is sent to the server when the
+ <option>--master-data</option> option is enabled. This prevents
+ the <literal role="stmt" condition="flush">FLUSH
+ TABLES</literal> statement from replicating to slaves, which is
+ disadvantageous because it would cause slaves to block while the
+ statement executes.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="ORDER BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37830"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal>InnoDB</literal> tables, <literal>ORDER BY ...
+ DESC</literal> sometimes returned results in ascending order.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35477"/>
+ <fixes bugid="35478"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Index scans performed with the <literal>sort_union()</literal>
+ access method returned wrong results, caused memory to be
+ leaked, and caused temporary files to be deleted when the limit
+ set by <literal>sort_buffer_size</literal> was reached.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="InnoDB"/>
+ <manual type="SHOW STATUS"/>
+ <manual type="Innodb_buffer_pool_pages_latched"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36600"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">SHOW STATUS</literal> took a lot of CPU
+ time for calculating the value of the
+ <literal>Innodb_buffer_pool_pages_latched</literal> status
+ variable. Now this variable is calculated and included in the
+ output of <literal role="stmt">SHOW STATUS</literal> only when
+ the <literal>UNIV_DEBUG</literal> symbol is defined at server
+ build time.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36632"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>SELECT DISTINCT</literal> from a simple view on an
+ <literal>InnoDB</literal> table, where all selected columns
+ belong to the same unique index key, returned incorrect results.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="prepared statements"/>
+ <manual type="stored procedures"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="12093"/>
+ <fixes bugid="21294"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ After executing a prepared statement that accesses a stored
+ function, the next execution would fail to find the function if
+ the stored function cache was flushed in the meantime.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="query cache"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33362"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Cached queries that used 256 or more tables were not properly
+ cached, so that later query invalidation due to a
+ <literal role="stmt" condition="truncate">TRUNCATE
+ TABLE</literal> for one of the tables caused the server to hang.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="UUID()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33748"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The internal functions <function>my_getsystime()</function>,
+ <function>my_micro_time()</function>, and
+ <function>my_micro_time_and_time()</function> did not work
+ correctly on Windows. One symptom was that uniqueness of
+ <literal role="func">UUID()</literal> values could be
+ compromised.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ALTER TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33873"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Fast <literal role="stmt">ALTER TABLE</literal> operations were
+ not fast for columns that used multibyte character sets.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ <manual type="KILL"/>
+ <manual type="SUM()"/>
+ <manual type="AVG()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37627"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Killing a query that used an <literal>EXISTS</literal> subquery
+ as the argument to <literal role="func">SUM()</literal> or
+ <literal role="func">AVG()</literal> caused a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="InnoDB"/>
+ <manual type="symbolic links"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="11894"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Windows, moving an <literal>InnoDB</literal>
+ <filename>.ibd</filename> file and then symlinking to it in the
+ database directory using a <filename>.sym</filename> file caused
+ a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="RESTORE"/>
+ <manual type="events"/>
+ <manual type="triggers"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36530"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">RESTORE</literal> could fail if the server
+ on which the restore operation took place had enabled triggers
+ or events.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="REPLACE"/>
+ <manual type="innodb_autoinc_lock_mode"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35602"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal>InnoDB</literal> tables,
+ <literal role="stmt">REPLACE</literal> statements used
+ <quote>traditional</quote> style locking, regardless of the
+ setting of <literal>innodb_autoinc_lock_mode</literal>. Now
+ <literal role="stmt">REPLACE</literal> works the same way as
+ <quote>simple inserts</quote> instead of using the old locking
+ algorithm. (<literal role="stmt">REPLACE</literal> statements
+ are treated in the same way as as
+ <literal role="stmt">INSERT</literal> statements.)
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="innodb_table_locks"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37669"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Setting the session value of the
+ <literal>innodb_table_locks</literal> system variable caused a
+ server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="SELECT"/>
+ <manual type="SQL_CACHE"/>
+ <manual type="SQL_NO_CACHE"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35020"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The use of the <literal>SQL_CACHE</literal> and
+ <literal>SQL_NO_CACHE</literal> options in
+ <literal role="stmt">SELECT</literal> statements now is checked
+ more restrictively: 1) Previously, both options could be given
+ in the same statement. This is no longer true; only one can be
+ given. 2) Previously, these options could be given in
+ <literal role="stmt">SELECT</literal> statements that were not
+ at the top-level. This is no longer true; the options are
+ disallowed in subqueries (including subqueries in the
+ <literal>FROM</literal> clause, and
+ <literal role="stmt">SELECT</literal> statements in unions other
+ than the first <literal role="stmt">SELECT</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34409"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A significant slowdown occurred when many
+ <literal role="stmt">SELECT</literal> statements that return
+ many rows from <literal>InnoDB</literal> tables were running
+ concurrently.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="binary log"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37027"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If the server failed to expire binary log files at startup, it
+ could crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Unicode"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32390"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Inserting <literal>CURRENT_TIME</literal>,
+ <literal>CURRENT_DATE</literal>, or
+ <literal>CURRENT_TIMESTAMP</literal> into a
+ <literal role="type">VARCHAR</literal> column didn't work for
+ non-ASCII character sets such as <literal>ucs2</literal>,
+ <literal>utf16</literal>, or <literal>utf32</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ORDER BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33791"/>
+ <fixes bugid="30462"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>ORDER BY</literal> failed to take into account accents
+ and lettercases in multi-level collations
+ (<literal>latin2_czech_cs</literal> and
+ <literal>cp1250_czech_cs</literal>).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ORDER BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33073"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Unindexed <literal>ORDER BY</literal> did not work on short
+ <literal>utf32</literal> columns, or on <literal>utf16</literal>
+ columns with a short <literal>max_sort_length</literal> value.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CHAR()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36418"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="func">CHAR(256 USING utf32)</literal> could
+ generate a result with an incorrect length and result in a
+ server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Unicode"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32914"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ It was possible to insert invalid Unicode characters (with code
+ point values greater than U+10FFFF) into <literal>utf8</literal>
+ and <literal>utf32</literal> columns.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="stored functions"/>
+ <manual type="user-defined functions"/>
+ <manual type="DROP FUNCTION"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31767"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal>DROP FUNCTION
+ <replaceable>db_name</replaceable>.<replaceable>func_name</replaceable></literal>
+ (that is, when the function name is qualified with the database
+ name), the statement should apply only to a stored function
+ named <filename>func_name</filename> in the given database.
+ However, if a UDF with the same name existed, the statement
+ dropped the UDF instead.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="sql_mode"/>
+ <manual type="mysql_install_db"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34159"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.67"/>
+ <version ver="5.0.68"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql_install_db</command> failed if the server was
+ running with an SQL mode of <literal>TRADITIONAL</literal>. This
+ program now resets the SQL mode internally to avoid this
+ problem.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ <manual type="NOT IN"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37761"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server returned unexpected results if a right side of the
+ <literal>NOT IN</literal> clause consisted of the
+ <literal>NULL</literal> value and some constants of the same
+ type. For example, this query might return 3, 4, 5, and so forth
+ if a table contained those values:
+ </para>
+
+<programlisting>
+SELECT * FROM t WHERE NOT t.id IN (NULL, 1, 2);
+</programlisting>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="INFORMATION_SCHEMA"/>
+ <manual type="DROP TABLESPACE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31302"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Making <literal>INFORMATION_SCHEMA</literal> the default
+ database caused the <literal>DROP TABLESPACE</literal> statement
+ to be disabled.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysqltest"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37003"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.27"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqltest</command> now installs signal handlers and
+ generates a stack trace if it crashes.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql-test-run.pl"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31880"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.56"/>
+ <version ver="5.1.23"/>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql-test-run.pl</command> sometimes set up test
+ scenarios in which the same port number was passed to multiple
+ servers, causing one of them to be unable to start.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="securityenhancement"/>
+ <manual type="user-defined-functions"/>
+ <manual type="plugin_dir"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37428"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.66sp1"/>
+ <version ver="5.0.67"/>
+ <version ver="5.0.70"/>
+ </versions>
+
+ <message>
+
+ <para>
+ To enable stricter control over the location from which
+ user-defined functions can be loaded, the
+ <literal>plugin_dir</literal> system variable has been
+ backported from MySQL 5.1. If the value is non-empty,
+ user-defined function object files can be loaded only from the
+ directory named by this variable. If the value is empty, the
+ behavior that is used prior to the inclusion of
+ <literal>plugin_dir</literal> applies: The UDF object files must
+ be located in a directory that is searched by your system's
+ dynamic linker.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MERGE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35274"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Accessing a <literal>MERGE</literal> table with an empty
+ underlying table list incorrectly resulted in a <quote>wrong
+ index</quote> error message rather than <quote>end of
+ file.</quote>
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37012"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Unix, it is now possible for the output file for
+ <literal role="stmt">BACKUP DATABASE</literal> to be an existing
+ FIFO.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="myisam_max_extra_sort_file_size"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38371"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The Windows <filename>my-template.ini</filename> template file
+ contained a reference to the
+ <literal>myisam_max_extra_sort_file_size</literal> system
+ variable, which no longer exists, causing the installed server
+ to fail upon startup.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="RESTORE"/>
+ <manual type="MyISAM"/>
+ <manual type="views"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36782"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For a view that referred to a <literal>MyISAM</literal> table,
+ the contents of the table could be empty after
+ <literal role="stmt">BACKUP DATABASE</literal> followed by
+ <literal role="stmt">RESTORE</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36778"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Data loss could be caused by attempts to read data from a
+ database being restored by a
+ <literal role="stmt">RESTORE</literal> operation.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="RESTORE"/>
+ <manual type="triggers"/>
+ <manual type="MyISAM"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36749"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Data loss could be caused by activation of a trigger for a
+ <literal>MyISAM</literal> table being restored by a
+ <literal role="stmt">RESTORE</literal> operation.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33120"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">BACKUP DATABASE</literal> did not properly
+ set the flags in the first two bytes of the backup image.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33355"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If the <literal>mysql</literal> database was named in the
+ <literal role="stmt">BACKUP DATABASE</literal> statement, the
+ backup operation hung.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33568"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If a large number of databases were named in the
+ <literal role="stmt">BACKUP DATABASE</literal> statement, the
+ server crashed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35806"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The current system time (as returned by
+ <literal role="func">NOW()</literal> or synonyms) became
+ constant after a <literal role="stmt">RESTORE</literal>
+ operation.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33573"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="type">TIMESTAMP</literal> columns were restored
+ to the current date and time (not their actual values) by a
+ <literal role="stmt">RESTORE</literal> operation.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="RESTORE"/>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34210"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal>InnoDB</literal> tables, loss of data resulted from
+ performing inserts concurrently with a
+ <literal role="stmt">RESTORE</literal> operation.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34758"/>
+ <fixes bugid="35347"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">BACKUP DATABASE</literal> caused a server
+ crash if it attempted to back up a view that depended on another
+ view.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34965"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>engines</literal> column in the
+ <literal>mysql.online_backup</literal> table has been renamed to
+ <literal>drivers</literal> to better reflect its contents.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35249"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">BACKUP DATABASE</literal> caused a server
+ crash upon encountering a table row that has been marked for
+ deletion but not removed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36257"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The project files created for Windows were missing the
+ <literal>GenError</literal> project dependency.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="36586"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On 64-bit platforms, <literal role="stmt">BACKUP
+ DATABASE</literal> hung for backups of more than 32KB.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="36624"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The online backup stream library failed to parse the backup
+ stream on 64-bit systems.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36323"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The default drivers for <literal role="stmt">BACKUP
+ DATABASE</literal> and <literal role="stmt">RESTORE</literal>
+ now support a cancel operation, which also allows better cleanup
+ if a driver error occurs.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="perror"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="10143"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>perror</command> did not work for errors described in
+ the <filename>sql/share/errmsg.txt</filename> file.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="error messages"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29738"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The Serbian translation for the
+ <literal>ER_INCORRECT_GLOBAL_LOCAL_VAR</literal> error was
+ corrected.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="FLUSH PRIVILEGES"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="21226"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="stmt" condition="flush">FLUSH
+ PRIVILEGES</literal> statement did not produce an error when it
+ failed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SHOW FUNCTION CODE"/>
+ <manual type="SHOW PROCEDURE CODE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33637"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="stmt">SHOW FUNCTION CODE</literal> and
+ <literal role="stmt">SHOW PROCEDURE CODE</literal> statements
+ are not present in non-debug builds, but attempting to use them
+ resulted in a <quote>syntax error</quote> message. Now the error
+ message indicates that the statements are disabled and that you
+ must use a debug build.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="cursors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38486"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Server-side cursors were not initialized properly, which could
+ cause a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Several improvements were made to MySQL Backup (the
+ <literal role="stmt">BACKUP DATABASE</literal> and
+ <literal role="stmt">RESTORE</literal> statements):
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Drivers are now included for storage engines that do not
+ store any data or rely on other storage engines for data
+ storage: <literal>MERGE</literal>,
+ <literal>FEDERATED</literal>, <literal>BLACKHOLE</literal>,
+ <literal>EXAMPLE</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The backup kernel better determines the dependency ordering
+ of objects to be backed up so that they can be restored in
+ the proper order.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Restored events and triggers are not reactivated until the
+ restore operation completes.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Improvements made to MySQL Backup (the
+ <literal role="stmt">BACKUP DATABASE</literal> and
+ <literal role="stmt">RESTORE</literal> statements):
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ A native driver for the <literal>MyISAM</literal> storage
+ engine is included. This results in faster times for backup
+ and restore operations, although the size of backup image
+ files is larger.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="OPTIMIZE TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34286"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <literal role="stmt">OPTIMIZE TABLE</literal> as the first
+ statement on an <literal>InnoDB</literal> table with an
+ <literal>AUTO_INCREMENT</literal> column could cause a server
+ crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql_upgrade"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31605"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql_upgrade</command> attempted to use the
+ <filename>/proc</filename> filesystem even on systems that do
+ not have it.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="utf8"/>
+ <manual type="utf8mb3"/>
+ <manual type="mysql_upgrade"/>
+ <manual type="event scheduler"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33002"/>
+ <fixes bugid="33053"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ After an upgrade to MySQL 6.0.4 or higher, columns that used the
+ old 3-byte Unicode <literal>utf8</literal> character set are
+ treated as having the <literal>utf8mb3</literal> character set.
+ <command>mysql_upgrade</command> did not convert all system
+ tables in the <literal>mysql</literal> database to use the new
+ 4-byte Unicode <literal>utf8</literal> character set rather than
+ <literal>utf8mb3</literal>. This caused problems such as that
+ the event scheduler would not start.
+ <command>mysql_upgrade</command> now performs the
+ <literal>utf8mb3</literal> to <literal>utf8</literal> conversion
+ for system tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="utf8"/>
+ <manual type="utf8_hungarian_ci"/>
+ <manual type="configure"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35808"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <command>configure</command> script did not allow
+ <literal>utf8_hungarian_ci</literal> to be specified as the
+ default collation.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="IF()"/>
+ <manual type="SUM()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37662"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Nesting of <literal role="func">IF()</literal> inside of
+ <literal role="func">SUM()</literal> could cause an extreme
+ server slowdown.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="table definition cache"/>
+ <manual type="BLOB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38002"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If the table definition cache contained tables with many
+ <literal role="type">BLOB</literal> columns, much memory could
+ be allocated to caching <literal role="type">BLOB</literal>
+ values. Now a size limit on the cached
+ <literal role="type">BLOB</literal> values is enforced.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="securityenhancement"/>
+ <manual type="parser"/>
+ <manual type="syntax"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38296"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.66sp1"/>
+ <version ver="5.0.68"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server consumed excess memory while parsing statements with
+ hundreds or thousands of nested boolean conditions (such as
+ <literal>OR (OR ... (OR ... ))</literal>). This could lead to a
+ server crash or incorrect statement execution, or cause other
+ client statements to fail due to lack of memory. The latter
+ result constitutes a denial of service.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysqltest"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="23921"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.26"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqltest</command> was changed to be more robust in
+ the case of a race condition that can occur for rapid
+ disconnect/connect sequences with the server. The account used
+ by <command>mysqltest</command> could reach its allowed
+ simultaneous-sessions user limit if the connect attempt occurred
+ before the server had fully processed the preceding disconnect.
+ <command>mysqltest</command> now checks specificaly for a
+ user-limits error when it connects; if that error occurs, it
+ delays briefly before retrying.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38108"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>MyISAM</literal> backup driver was subject to a
+ race condition that allowed multiple
+ <literal role="stmt">RESTORE</literal> operations to occur
+ simultaneously. This could result in locking conflicts,
+ incorrect entries in the progress tables, or other problems.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="metadata"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37301"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>max_length</literal> result set metadata value was
+ calculated incorrectly under some circumstances.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="--myisam-recover"/>
+ <manual type="MyISAM"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35161"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>MyISAM</literal> recovery enabled with the
+ <option>--myisam-recover</option> option did not work for
+ partitioned <literal>MyISAM</literal> tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="REGEXP"/>
+ <manual type="stored programs"/>
+ <manual type="prepared statements"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37337"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Within stored programs or prepared statements,
+ <literal role="op">REGEXP</literal> could return incorrect
+ results due to improper initialization.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="MyISAM"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37537"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>myisamchk</command> failed with an assertion error when
+ analyzing a partitioned <literal>MyISAM</literal> table.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="HOME environment variable"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30394"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Several MySQL programs could fail if the <literal>HOME</literal>
+ environment variable had an empty value.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Debian"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27526"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <command>BUILD/check-cpu</command> build script failed if
+ <command>gcc</command> had a different name (such as
+ <command>gcc.real</command> on Debian).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="key_buffer_size"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35616"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On 64-bit systems, assigning values of 2
+ <superscript>63</superscript> − 1 or larger to
+ <literal role="sysvar">key_buffer_size</literal> caused memory
+ overruns.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysql-test-run.pl"/>
+ <manual type="--combination"/>
+ <manual type="combinations file"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.23"/>
+ <version ver="6.0.4"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql-test-run.pl</command> now supports a
+ <option>--combination</option> option for specifying options to
+ the <command>mysqld</command> server. This option is similar to
+ <option>--mysqld</option> but should be given two or more times.
+ <command>mysql-test-run.pl</command> executes multiple test
+ runs, using the options for each instance of
+ <option>--combination</option> in successive runs.
+ </para>
+
+ <para>
+ For test runs specific to a given test suite, an alternative to
+ the use of <option>--combination</option> is to create a
+ <filename>combinations</filename> file in the suite directory.
+ The file should contain a section of options for each test run.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysql-test-run.pl"/>
+ <manual type="mysqltest"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql-test-run.pl</command> now supports a
+ <option>--mysqltest</option> option for specifying options to
+ the <command>mysqltest</command> program.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="syntax"/>
+ <manual type="CHECK"/>
+ <manual type="CONSTRAINT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35578"/>
+ <fixes bugid="11714"/>
+ <fixes bugid="38696"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal role="stmt">CREATE TABLE</literal>, the parser did
+ not enforce that parentheses were present in a <literal>CHECK
+ (<replaceable>expr</replaceable>)</literal> clause; now it does.
+ The parser did not enforce that <literal>CONSTRAINT
+ [<replaceable>symbol</replaceable>]</literal> without a
+ following <literal>CHECK</literal> clause was illegal; now it
+ does.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36135"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server could crash with an assertion failure (or cause the
+ client to get a <quote>Packets out of order</quote> error) when
+ the expected query result was that it should terminate with a
+ <quote>Subquery returns more than 1 row</quote> error.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="SHOW ENGINE INNODB STATUS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36941"/>
+ <fixes bugid="36942"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some performance problems of
+ <literal role="stmt" condition="show-engine">SHOW ENGINE INNODB
+ STATUS</literal> were reduced by removing <literal>used
+ cells</literal> and <literal>Total number of lock structs in row
+ lock hash table</literal> from the output. These values are now
+ present only if <literal>UNIV_DEBUG</literal> is defined at
+ MySQL build time.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36795"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Server crashed when starting a new <literal role="stmt">BACKUP
+ DATABASE</literal> or <literal role="stmt">RESTORE</literal>
+ statement while a <literal role="stmt">BACKUP DATABASE</literal>
+ or <literal role="stmt">RESTORE</literal> was ongoing.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="locking"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36579"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.70"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Dumping information about locks in use by sending a
+ <literal>SIGHUP</literal> signal to the server or by invoking
+ the <command>mysqladmin debug</command> command could lead to a
+ server crash in debug builds or to undefined behavior in
+ production builds.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="valgrind"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38290"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A failure to clean up binary log events was corrected (detected
+ by Valgrind).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="stored procedures"/>
+ <manual type="views"/>
+ <manual type="valgrind"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38291"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.70"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A server crash or Valgrind warnings could result when a stored
+ procedure selected from a view that referenced a function.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="TRUNCATE"/>
+ <manual type="AUTO_INCREMENT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37531"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ After <literal role="stmt" condition="truncate">TRUNCATE
+ TABLE</literal> for an <literal>InnoDB</literal> table,
+ inserting explicit values into an
+ <literal>AUTO_INCREMENT</literal> column could fail to increment
+ the counter and result in a duplicate-key error for subsequent
+ insertion of <literal>NULL</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="locking"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38185"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Over-aggressive lock acquisition by <literal>InnoDB</literal>
+ when calculating free space for tablespaces could result in
+ performance degradation when multiple threads were executing
+ statements on multi-core machines.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CSV"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36638"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>CSV</literal> storage engine returned success even
+ when it failed to open a table's data file.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql_install_db"/>
+ <manual type="NetWare"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="30129"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.68"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On NetWare, <command>mysql_install_db</command> could appear to
+ execute normally even if it failed to create the initial
+ databases.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="DECIMAL"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36270"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When the fractional part in a multiplication of
+ <literal role="type">DECIMAL</literal> values overflowed, the
+ server truncated the first operand rather than the longest. Now
+ the server truncates so as to produce more precise
+ multiplications.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="INFORMATION_SCHEMA"/>
+ <manual type="INSTALL PLUGIN"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36399"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If initialization of an <literal>INFORMATION_SCHEMA</literal>
+ plugin failed, <literal role="stmt">INSTALL PLUGIN</literal>
+ freed some internal plugin data twice.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MyISAM"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37310"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.70"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For a <literal>MyISAM</literal> table with <literal>CHECKSUM =
+ 1</literal> and <literal>ROW_FORMAT = DYNAMIC</literal> table
+ options, a data consistency check (maximum record length) could
+ fail and cause the table to be marked as corrupted.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="FEDERATED"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34779"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Table checksum calculation could cause a server crash for
+ <literal>FEDERATED</literal> tables with
+ <literal role="type">BLOB</literal> columns containing
+ <literal>NULL</literal> values.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="valgrind"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38746"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Falcon</literal> did not build on Linux with Valgrind
+ enabled.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="AMD64"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38535"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Falcon</literal> builds on AMD64 platforms now.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Falcon"/>
+ <manual type="BLOB"/>
+ <manual type="TEXT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35688"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Following a server crash, recovery of <literal>Falcon</literal>
+ tables containing <literal role="type">BLOB</literal> or
+ <literal role="type">TEXT</literal> columns could lose data.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="INFORMATION_SCHEMA"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35490"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In the <literal>INFORMATION_SCHEMA</literal> database, the
+ <literal>FALCON_DATABASE_IO</literal> table was renamed to
+ <literal>FALCON_TABLESPACE_IO</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="BINLOG"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A new statement, <literal role="stmt">BINLOG</literal>, is
+ generated by <command>mysqlbinlog</command> to represent
+ row-based events in binary log files. The statement argument, a
+ base 64-encoded string, is decoded by the server to determine
+ the data change indicated by the corresponding event.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <manual type="mysqlbinlog"/>
+ <manual type="--base64-output=DECODE-ROWS"/>
+ <manual type="--verbose"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31455"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqlbinlog</command> now supports
+ <option>--verbose</option> and
+ <option>--base64-output=DECODE-ROWS</option> options to display
+ row events as commented SQL statements. (The default otherwise
+ is to display row events encoded as base-64 strings using
+ <literal role="stmt">BINLOG</literal> statements.) See
+ <xref linkend="mysqlbinlog-row-events"/>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33023"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">BACKUP DATABASE</literal> followed by
+ <literal role="stmt">RESTORE</literal> could mangle object names
+ if a non-standard charset was used.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer_switch"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37120"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>optimizer_switch</literal> system variable takes a
+ comma-separated list of values, but only the first value in the
+ list was used.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35468"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For uncorrelated subqueries without a <literal>WHERE</literal>
+ clause, use of semi-join or materialization options could result
+ in slow performance, or use of the LooseScan strategy could
+ produce incorrect results.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37548"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When using indexed <literal>ORDER BY</literal> sorting,
+ incorrect query results could be produced if the optimizer
+ switched from a covering index to a non-covering index.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38195"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.70"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Incorrect handling of aggregate functions when loose index scan
+ was used caused a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BIT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37799"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If a table has a <literal>BIT NOT NULL</literal> column
+ <literal>c1</literal> with a length shorter than 8 bits and some
+ additional <literal>NOT NULL</literal> columns
+ <literal>c2</literal>, ..., and a
+ <literal role="stmt">SELECT</literal> query has a
+ <literal>WHERE</literal> clause of the form <literal>(c1 =
+ <replaceable>constant</replaceable>) AND c2 ...</literal>, the
+ query could return an unexpected result set.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="backupdir"/>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35230"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A new system variable, <literal>backupdir</literal>, enables the
+ default directory to be specified for
+ <literal role="stmt">BACKUP DATABASE</literal> and
+ <literal role="stmt">RESTORE</literal> operations when the image
+ file pathname is not a full pathname. The default value for this
+ variable is the data directory.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="Debug Sync"/>
+ <manual type="--enable-debug-sync"/>
+ <manual type="--debug-sync-timeout"/>
+ <manual type="debug_sync"/>
+ <manual type="mysql-test-run.pl"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server now supports a Debug Sync facility for thread
+ synchronization during testing and debugging. To compile in this
+ facility, configure MySQL with the
+ <option>--enable-debug-sync</option> option. The
+ <literal role="sysvar">debug_sync</literal> system variable
+ provides the user interface Debug Sync.
+ <command>mysqld</command> and
+ <command>mysql-test-run.pl</command> support a
+ <option>--debug-sync-timeout</option> option to enable the
+ facility and set the default synchronization point timeout.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="mysql-test-run.pl"/>
+ <manual type="--client-bindir"/>
+ <manual type="--client-libdir"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34995"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.66"/>
+ <version ver="5.1.27"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql-test-run.pl</command> now supports
+ <option>--client-bindir</option> and
+ <option>--client-libdir</option> options for specifying the
+ directory where client binaries and libraries are located.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ <manual type="online_backup"/>
+ <manual type="online_backup_progress"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33836"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>mysql.online_backup</literal> and
+ <literal>mysql.online_backup_progress</literal> tables now have
+ a default character set of <literal>utf8</literal> rather than
+ <literal>latin1</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="views"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34867"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If a view was altered before backing up a database,
+ <literal role="stmt">BACKUP DATABASE</literal> caused a server
+ crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="views"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34902"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If a view depended on a base table that had been dropped,
+ <literal role="stmt">BACKUP DATABASE</literal> caused a server
+ crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Unicode"/>
+ <manual type="utf8"/>
+ <manual type="ALTER TABLE"/>
+ <manual type="TEXT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26180"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">ALTER TABLE</literal> could not be used to
+ add columns to a table if the table had an index on a
+ <literal>utf8</literal> column with a
+ <literal role="type">TEXT</literal> data type.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="CSV"/>
+ <manual type="CHAR"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35117"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>CSV</literal> tables with
+ <literal role="type">CHAR</literal> columns caused
+ <literal role="stmt">BACKUP DATABASE</literal> to produce a
+ server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39059"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some warnings were being reported as errors.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36777"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some warnings were being reported as errors.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="views"/>
+ <manual type="privileges"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36086"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In some cases, references to views were confused with references
+ to anonymous tables and privilege checking was not performed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="<=>"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37526"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.70"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="op" condition="equal-to"><=></literal>
+ operator could return incorrect results when comparing
+ <literal>NULL</literal> to <literal role="type">DATE</literal>,
+ <literal role="type">TIME</literal>, or
+ <literal role="type">DATETIME</literal> values.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SHOW PROCEDURE STATUS"/>
+ <manual type="SHOW FUNCTION STATUS"/>
+ <manual type="privileges"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37908"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Access checks were skipped for <literal role="stmt">SHOW
+ PROCEDURE STATUS</literal> and <literal role="stmt">SHOW
+ FUNCTION STATUS</literal>, which could lead to a server crash or
+ insufficient access checks in subsequent statements.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38701"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When inserting a string into a duplicate-key error message, the
+ server could improperly interpret the string, resulting in a
+ crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="WEIGHT_STRING()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29825"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A problem related to HP-UX compilers that caused incorrect
+ <literal role="func">WEIGHT_STRING()</literal> results was
+ fixed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="REGEXP"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39021"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.70"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Queries of the form <literal>SELECT ... REGEXP BINARY
+ NULL</literal> could lead to a hung or crashed server.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="AUTO_INCREMENT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38821"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.70"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Repeated <literal>CREATE TABLE ... SELECT</literal> statements,
+ where the created table contained an
+ <literal>AUTO_INCREMENT</literal> column, could lead to an
+ assertion failure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="INSERT"/>
+ <manual type="ON DUPLICATE KEY UPDATE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39002"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.70"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Statements of the form <literal>INSERT ... SELECT .. ON
+ DUPLICATE KEY UPDATE <replaceable>col_name</replaceable> =
+ DEFAULT</literal> could result in a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33907"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Changes to build files were made to enable the MySQL
+ distribution to compile on Microsoft Visual C++ Express 2008.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql_install_db"/>
+ <manual type="NDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31315"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql_install_db</command> failed if run with the
+ default table type set to <literal>NDB</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="views"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35395"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The method for enumerating view dependencies could cause the
+ server to deadlock.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="FEDERATED"/>
+ <manual type="ORDER BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32426"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Query results from a <literal>FEDERATED</literal> table were
+ corrupt if the query included an <literal>ORDER BY</literal> on
+ a <literal role="type">TEXT</literal> column.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="FEDERATED"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33702"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Attempts to access a <literal>FEDERATED</literal> table using a
+ non-existent server did not reliably return a proper error.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="valgrind"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38560"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An uninitialized variable in the query profiling code was
+ corrected (detected by Valgrind).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <highlight type="incompatiblechange"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37226"/>
+ <fixes bugid="33031"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.70"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message ver="5.0.70,5.1.28">
+
+ <para>
+ There were some problems using <function>DllMain()</function>
+ hook functions on Windows that automatically do global and
+ per-thread initialization for
+ <filename>libmysqld.dll</filename>:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Per-thread initialization: MySQL internally counts the
+ number of active threads, which causes a delay in
+ <function>my_end()</function> if not all threads have
+ exited. But there are threads that can be started either by
+ Windows internally (often in TCP/IP scenarios) or by users.
+ Those threads do not necessarily use
+ <filename>libmysql.dll</filename> functionality but still
+ contribute to the open-thread count. (One symptom is a
+ five-second delay in times for PHP scripts to finish.)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Process-initialization:
+ <literal role="cfunc">my_init()</literal> calls
+ <function>WSAStartup</function> that itself loads DLLs and
+ can lead to a deadlock in the Windows loader.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ To correct these problems, DLL initialization code now is not
+ invoked from <filename>libmysql.dll</filename> by default. To
+ obtain the previous behavior (DLL initialization code will be
+ called), set the <literal>LIBMYSQL_DLLINIT</literal> environment
+ variable to any value. This variable exists only to prevent
+ breakage of existing Windows-only applications that do not call
+ <literal role="cfunc">mysql_thread_init()</literal> and work
+ okay today. Use of <literal>LIBMYSQL_DLLINIT</literal> is
+ discouraged and is removed in MySQL 6.0.
+ </para>
+
+ </message>
+
+ <message ver="6.0.7">
+
+ <para>
+ There were some problems using <function>DllMain()</function>
+ hook functions on Windows that automatically do global and
+ per-thread initialization for
+ <filename>libmysqld.dll</filename>:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Per-thread initialization: MySQL internally counts the
+ number of active threads, which causes a delay in
+ <function>my_end()</function> if not all threads have
+ exited. But there are threads that can be started either by
+ Windows internally (often in TCP/IP scenarios) or by users.
+ Those threads do not necessarily use
+ <filename>libmysql.dll</filename> functionality but still
+ contribute to the open-thread count. (One symptom is a
+ five-second delay in times for PHP scripts to finish.)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Process-initialization:
+ <literal role="cfunc">my_init()</literal> calls
+ <function>WSAStartup</function> that itself loads DLLs and
+ can lead to a deadlock in the Windows loader.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ To correct these problems, DLL initialization code now is not
+ invoked from <filename>libmysql.dll</filename> by default.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39189"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For <literal role="stmt">BACKUP DATABASE</literal>, the server
+ could add a <literal>/</literal> character to the end of the
+ backup path, even when the path ended with a filename rather
+ than a directory name.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39127"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">BACKUP DATABASE</literal> failed on
+ PowerMac platforms due to type casting problems.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="i5/OS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35743"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Dynamic plugins failed to load on i5/OS.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="tablespaces"/>
+ <manual type="logfile groups"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="priv">CREATE TABLESPACE</literal> privilege
+ has been introduced. This privilege exists at the global
+ (superuser) level and enables you to create, alter, and drop
+ tablespaces and logfile groups.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ <highlight type="incompatiblechange"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The tables for MySQL Backup logging have been renamed, and the
+ logging capabilities now are more flexible, similar to the
+ capabilities provided for the general query log and slow query
+ log.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The names of the MySQL Backup log tables in the
+ <literal>mysql</literal> database have been changed from
+ <literal>online_backup</literal> and
+ <literal>online_backup_progress</literal> to
+ <literal>backup_history</literal> and
+ <literal>backup_progress</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Logging now can be enabled or disabled, it is possible to
+ log to tables or to files, and the names of the log files
+ can be changed. For details, see
+ <xref linkend="backup-database-restore-log-control"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A new statement,
+ <literal role="stmt" condition="flush">FLUSH BACKUP
+ LOGS</literal>, closes and reopens the backup log files. A
+ new option for
+ <literal role="cfunc">mysql_refresh()</literal>,
+ <literal>REFRESH_BACKUP_LOG</literal>, performs the same
+ operation.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="RESTORE"/>
+ <manual type="secure_file_priv"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34171"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>secure_file_priv</literal> system variable now
+ applies to <literal role="stmt">BACKUP DATABASE</literal> and
+ <literal role="stmt">RESTORE</literal> operations: If the value
+ is nonempty, backup and restore operations can read and write
+ files only in the given directory.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38462"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The binary log filename stored in the
+ <literal>binlog_file</literal> column of the
+ <literal>mysql.backup_history</literal> MySQL Backup table now
+ is the file basename (the final component). Previously, the full
+ pathname was stored, but this could be too long for the column
+ width.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37522"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ MySQL Backup was not consistently checking for
+ <literal>BSTREAM_ERROR</literal> errors.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="RESTORE"/>
+ <manual type="BLOB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37212"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Incorrect <literal role="type">BLOB</literal> handling by
+ <literal role="stmt">RESTORE</literal> could result in a server
+ crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="backup_wait_timeout"/>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A new session system variable,
+ <literal role="sysvar">backup_wait_timeout</literal>, controls
+ the number of seconds a <literal role="stmt">BACKUP
+ DATABASE</literal> or <literal role="stmt">RESTORE</literal>
+ operation waits for a blocked DDL statements before aborting
+ with an error.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36531"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.5"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">BACKUP DATABASE</literal> did not correctly
+ determine dependency ordering of backed-up objects, which could
+ cause a <literal role="stmt">RESTORE</literal> operation to
+ fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ORDER BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36639"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.70"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A query which had an <literal>ORDER BY DESC</literal> clause
+ that is satisfied with a reverse range scan could cause a server
+ crash for some specific CPU/compiler combinations.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ <manual type="subqueries"/>
+ <manual type="DISTINCT"/>
+ <manual type="ORDER BY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38191"/>
+ </bugs>
+
+ <versions>
+ <version ver="4.1.25"/>
+ <version ver="5.0.70"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Queries containing a subquery with <literal>DISTINCT</literal>
+ and <literal>ORDER BY</literal> could cause a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="UPDATE"/>
+ <manual type="FLUSH TABLES WITH READ LOCK"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38691"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A server crash resulted from concurrent execution of a
+ multiple-table <literal role="stmt">UPDATE</literal> that used a
+ <literal>NATURAL</literal> or <literal>USING</literal> join
+ together with <literal role="stmt" condition="flush">FLUSH
+ TABLES WITH READ LOCK</literal> or <literal role="stmt">ALTER
+ TABLE</literal> for the table being updated.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="stored procedures"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38823"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Column names constructed due to wild-card expansion done inside
+ a stored procedure could point to freed memory if the expansion
+ was performed after the first call to the stored procedure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="UPDATE"/>
+ <manual type="FLUSH TABLES"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38499"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A server crash resulted from execution of an
+ <literal role="stmt">UPDATE</literal> that used a derived table
+ together with <literal role="stmt" condition="flush">FLUSH
+ TABLES</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38269"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In some cases, a replication master sent a special event to a
+ reconnecting slave to keep the slave's temporary tables, but
+ they still had references to the <quote>old</quote> slave SQL
+ thread and used them to access that thread's data.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <highlight type="incompatiblechange"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39812"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The default binary logging mode has been changed from
+ <literal>MIXED</literal> to <literal>STATEMENT</literal> for
+ compatibility with MySQL 5.0.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="plugins"/>
+ <manual type="Mac OS X"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37958"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The handlerton-to-plugin mapping implementation did not free
+ handler plugin references when the plugin was uninstalled,
+ resulting in a server crash after several install/uninstall
+ cycles. Also, on Mac OS X, the server crashed when trying to
+ access an <literal>EXAMPLE</literal> table after the
+ <literal>EXAMPLE</literal> plugin was installed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34707"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For a <literal>CREATE TABLE ... SELECT</literal> statement that
+ creates a table in a database other than the current one, the
+ table could be created in the wrong database on replication
+ slaves if row-based binary logging is used.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38005"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Using <literal>INSERT ... SELECT</literal> to insert records
+ into a partitioned <literal>MyISAM</literal> table could fail if
+ some partitions were empty and others are not.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <highlight type="replication"/>
+ <manual type="MyISAM"/>
+ <manual type="binlog"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35843"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Replication to partitioned <literal>MyISAM</literal> tables
+ could be slow with row-based binary logging.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="log tables"/>
+ <manual type="binary log"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34306"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ With binary logging enabled, <literal>CREATE TABLE ...
+ SELECT</literal> failed if the source table was a log table.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqldump"/>
+ <manual type="views"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31434"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.70"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqldump</command> could fail to dump views containing
+ a large number of columns.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="transactions"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38804"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For deadlock between two transactions that required a timeout to
+ resolve, all server tables became inaccessible for the duration
+ of the deadlock.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="stored procedures"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38469"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Stored procedures involving substrings could crash the server on
+ certain platforms due to invalid memory reads.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ALTER EVENT"/>
+ <manual type="PRESERVE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35981"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">ALTER EVENT</literal> changed the
+ <literal>PRESERVE</literal> attribute of an event even when
+ <literal>PRESERVE</literal> was not specified in the statement.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="stored procedures"/>
+ <manual type="subqueries"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37949"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server crashed if an argument to a stored procedure was a
+ subquery that returned more than one row.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="stored procedures"/>
+ <manual type="NAME_CONST()"/>
+ <manual type="collations"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39182"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ References to local variables in stored procedures are replaced
+ with
+ <literal role="func">NAME_CONST(<replaceable>name</replaceable>,
+ <replaceable>value</replaceable>)</literal> when written to the
+ binary log. However, an <quote>illegal mix of collation</quote>
+ error might occur when executing the log contents if the value's
+ collation differed from that of the variable. Now information
+ about the variable collation is written as well.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38083"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If an error occurred when evaluating a column of a partitioned
+ table for the partitioning function, the row could be inserted
+ anyway.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="BLACKHOLE"/>
+ <highlight type="replication"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38360"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Replication of <literal>BLACKHOLE</literal> tables did not work
+ with row-based binary logging.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="TIMESTAMP"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39353"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.70"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For a <literal role="type">TIMESTAMP</literal> column in an
+ <literal>InnoDB</literal> table, testing the column with
+ multiple conditions in the <literal>WHERE</literal> clause
+ caused a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="variables"/>
+ <manual type="types"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="26020"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server could improperly type user-defined variables used in
+ the select list of a query.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CHECK TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39585"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>CHECK TABLE ... FOR UPGRADE</literal> did not check for
+ incompatible collation changes made in MySQL 5.0.48.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="AUTO_INCREMENT"/>
+ <manual type="InnoDB"/>
+ <manual type="triggers"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="31612"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A trigger for an <literal>InnoDB</literal> table activating
+ multiple times could lead to <literal>AUTO_INCREMENT</literal>
+ gaps.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <manual type="skip-thread-priority"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35164"/>
+ <fixes bugid="37536"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <option>--skip-thread-priority</option> option is now
+ deprecated in MySQL 5.1 and is removed in MySQL 6.0 such that
+ the server won't change the thread priorities by default. Giving
+ threads different priorities might yield marginal improvements
+ in some platforms (where it actually works), but it might
+ instead cause significant degradation depending on the thread
+ count and number of processors. Meddling with the thread
+ priorities is a not a safe bet as it is very dependent on the
+ behavior of the CPU scheduler and system where MySQL is being
+ run.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="36970"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If thread-pooling was used and a connection attempt was denied
+ on the grounds of exceeding the user limits, the number of
+ active connections for that user was erroneously decreased
+ twice. The difference between the actual number connections and
+ the internal count could then cause debug builds of the server
+ to raise an assertion.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="packaging"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="27742"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.48"/>
+ <version ver="5.0.51"/>
+ <version ver="5.1.28"/>
+ <version ver="6.0.6"/>
+ </versions>
+
+ <message>
+
+ <para>
+ MySQL source distributions are now available in Zip format.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="incompatiblechange"/>
+ <manual type="views"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="17823"/>
+ <seealsobug bugid="40021"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message ver="5.1.29">
+
+ <para>
+ In connection with view creation, the server created
+ <filename>arc</filename> directories inside database directories
+ and maintained useless copies of <filename>.frm</filename> files
+ there. Creation and renaming procedures of those copies as well
+ as creation of <filename>arc</filename> directories has been
+ discontinued.
+ </para>
+
+ <para>
+ This change does cause a problem when downgrading to older
+ server versions which manifests itself under these
+ circumstances:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Create a view <literal>v_orig</literal> in MySQL 5.1.29 or
+ higher.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Rename the view to <literal>v_new</literal> and then back to
+ <literal>v_orig</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Downgrade to an older 5.1.x server and run
+ <command>mysql_upgrade</command>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Try to rename <literal>v_orig</literal> to
+ <literal>v_new</literal> again. This operation fails.
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ <para>
+ As a workaround to avoid this problem, use either of these
+ approaches:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Dump your data using <command>mysqldump</command> before
+ downgrading and reload the dump file after downgrading.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Instead of renaming a view after the downgrade, drop it and
+ recreate it.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ <message ver="6.0.8">
+
+ <para>
+ In connection with view creation, the server created
+ <filename>arc</filename> directories inside database directories
+ and maintained useless copies of <filename>.frm</filename> files
+ there. Creation and renaming procedures of those copies as well
+ as creation of <filename>arc</filename> directories has been
+ discontinued.
+ </para>
+
+ <para>
+ This change does cause a problem when downgrading to older
+ server versions which manifests itself under these
+ circumstances:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Create a view <literal>v_orig</literal> in MySQL 6.0.8 or
+ higher.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Rename the view to <literal>v_new</literal> and then back to
+ <literal>v_orig</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Downgrade to an older 6.0.x server and run
+ <command>mysql_upgrade</command>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Try to rename <literal>v_orig</literal> to
+ <literal>v_new</literal> again. This operation fails.
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ <para>
+ As a workaround to avoid this problem, use either of these
+ approaches:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Dump your data using <command>mysqldump</command> before
+ downgrading and reload the dump file after downgrading.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Instead of renaming a view after the downgrade, drop it and
+ recreate it.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="views"/>
+ <manual type="INFORMATION_SCHEMA"/>
+ <manual type="SHOW CREATE VIEW"/>
+ <manual type="privileges"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="22763"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For access to the
+ <literal role="is">INFORMATION_SCHEMA.VIEWS</literal> table, the
+ server did not check the <literal role="priv">SHOW
+ VIEW</literal> and <literal role="stmt">SELECT</literal>
+ provileges, leading to inconsistency between output from that
+ table and the <literal role="stmt">SHOW CREATE VIEW</literal>
+ statement.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="PAD_CHAR_TO_FULL_LENGTH"/>
+ <manual type="ucs2"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35720"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ With the <literal>PAD_CHAR_TO_FULL_LENGTH</literal> SQL mode
+ enabled, a <literal>ucs2</literal>
+ <literal role="type">CHAR</literal> column returned additional
+ garbage after trailing space characters.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql_install_db"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35754"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysql_install_db</command> failed on machines that had
+ the hostname set to <literal>localhost</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35987"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For crash reports on Windows, symbol names in stack traces were
+ not correctly resolved.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="NO_BACKSLASH_ESCAPES"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37114"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.70"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>NO_BACKSLASH_ESCAPES</literal> SQL mode was ignored
+ for <literal role="stmt" condition="load-data">LOAD DATA
+ INFILE</literal> and <literal>SELECT INTO ... OUTFILE</literal>.
+ The setting is taken into account now.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql-test-run.pl"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38629"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On ActiveState Perl, <command>mysql-test-run.pl
+ --start-and-exit</command> started but did not exit.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="Solaris"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38727"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <filename>BUILD/compile-solaris-*</filename> scripts now
+ compile MySQL with the <literal>mtmalloc</literal> library
+ rather than <literal>malloc</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <manual type="logging"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <option>--log</option> option now is deprecated and will be
+ removed (along with the <literal>log</literal> system variable)
+ in the future. Instead, use the <option>--general_log</option>
+ option to enable the general query log and the
+ <option>--general_log_file=<replaceable>file_name</replaceable></option>
+ option to set the general query log filename. The values of
+ these options are available in the
+ <literal role="sysvar">general_log</literal> and
+ <literal role="sysvar">general_log_file</literal> system
+ variables, which can be changed at runtime.
+ </para>
+
+ <para>
+ Similar changes were made for the
+ <option>--log-slow-queries</option> option and
+ <literal role="sysvar">log_slow_queries</literal> system
+ variable. You should use the <option>--slow_query_log</option>
+ and
+ <option>--slow_query_log_file=<replaceable>file_name</replaceable></option>
+ options instead (and the <literal>slow_query_log</literal> and
+ <literal>slow_query_log_file</literal> system variables).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="35924"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Hostname values in SQL statements were not being checked for
+ <literal>'@'</literal>, which is illegal according to RFC952.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37943"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When analyzing the possible index use cases, the server was
+ incorrectly reusing an internal structure, leading to a server
+ crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="POSIX"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="24509"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On WIndows, use of POSIX I/O interfaces in
+ <literal>mysys</literal> was replaced with Win32 API calls
+ (<function>CreateFile()</function>,
+ <function>WriteFile()</function>, and so forth) and the default
+ maximum number of open files has been increased to 16384. The
+ maximum can be increased further by using the
+ <option>--max-open-files=<replaceable>N</replaceable></option>
+ option at server startup.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35240"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">RESTORE</literal> did not set the
+ <literal>validity_point_time</literal>,
+ <literal>binlog_pos</literal>, and
+ <literal>binlog_file</literal> fields of the
+ <literal>backup_history</literal> log table row.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38261"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">BACKUP DATABASE</literal> now performs an
+ implicit commit, like <literal role="stmt">RESTORE</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="37854"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Comparisons could hang for <literal>SET</literal> or
+ <literal role="type">ENUM</literal> columns that used
+ <literal>latin2_czech_cs</literal> collation.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SET"/>
+ <manual type="utf8"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39186"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server could crash when attempting to insert duplicate empty
+ strings into a <literal>utf8</literal> <literal>SET</literal>
+ column.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="--thread-handling"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39916"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>Threads_created</literal> status variable was not
+ correctly incremented when the server was started with the
+ <option>--thread-handling=pool-of-threads</option> option.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="IPv6"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39153"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Hostname lookup failure could lead to a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33352"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server crashed for <literal role="stmt">BACKUP
+ DATABASE</literal> if the backup progress tables in the
+ <literal>mysql</literal> database were missing or created
+ incorrectly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="38692"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.29"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A race condition between threads sometimes caused unallocated
+ memory to be addressed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="--default-table-type"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34818"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The deprecated <option>--default-table-type</option> server
+ option has been removed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="implicit commit"/>
+ <manual type="ANALYZE TABLE"/>
+ <manual type="CHECK TABLE"/>
+ <manual type="OPTIMIZE TABLE"/>
+ <manual type="REPAIR TABLE"/>
+ </tags>
+
+ <versions>
+ <version ver="5.1.10"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The following statements now cause an implicit commit:
+ <literal role="stmt">ANALYZE TABLE</literal>,
+ <literal role="stmt">CHECK TABLE</literal>,
+ <literal role="stmt">OPTIMIZE TABLE</literal>, and
+ <literal role="stmt">REPAIR TABLE</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Windows"/>
+ <manual type="mc.exe"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40280"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mc.exe</command> is no longer needed to compile MySQL
+ on Windows. This makes it possible to build MySQL from source
+ using Visual Studio Express 2008.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39844"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server could crash during a sort-order optimization of a
+ dependent subquery.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="filesort"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39283"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server returned a column type of
+ <literal role="type">VARBINARY</literal> rather than
+ <literal role="type">DATE</literal> as the result from the
+ <literal role="func">COALESCE()</literal>,
+ <literal role="func">IFNULL()</literal>,
+ <literal role="func">IF()</literal>,
+ <literal role="func">GREATEST()</literal>, or
+ <literal role="func">LEAST()</literal> functions or
+ <literal role="op">CASE</literal> expression if the result was
+ obtained using <literal>filesort</literal> in an anonymous
+ temporary table during the query execution.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="38693"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If delayed insert failed to upgrade the lock, it did not free
+ the temporary memory storage used to keep newly constructed
+ <literal role="type">BLOB</literal> values in memory, resulting
+ in a memory leak.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="LIMIT"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37075"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On a 32-bit server built without big tables support, the offset
+ argument in a <literal>LIMIT</literal> clause might be truncated
+ due to a 64-bit to 32-bit cast.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="37961"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Errors during server startup caused destruction of an
+ uninitialized mutex and assertion failure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="37894"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A <literal role="stmt">SELECT</literal> with a <literal>NULL NOT
+ IN</literal> condition containing a complex subquery from the
+ same table as in the outer select caused an assertion failure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="SHOW PROCESSLIST"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37550"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">SHOW PROCESSLIST</literal> displayed
+ <quote>copy to tmp table</quote> when no such copy was
+ occurring.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysql_real_connect()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33831"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="cfunc">mysql_real_connect()</literal> did not
+ check whether the <literal>MYSQL</literal> connection handler
+ was already connected and connected again even if so. Now an
+ <literal>CR_ALREADY_CONNECTED</literal> error occurs.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CHECKSUM TABLE"/>
+ <manual type="KILL QUERY"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33146"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">CHECKSUM TABLE</literal> was not killable
+ with <literal role="stmt" condition="kill">KILL QUERY</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="XA"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="28323"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.30"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ XA transaction rollbacks could result in corrupted transaction
+ states and a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39949"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Non-ASCII error messages were corrupted.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="implicit commits"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Most statements that previously caused an implicit commit before
+ executing now also cause an implicit commit after executing.
+ Also, the <literal role="stmt">FLUSH</literal> statement and
+ <literal role="cfunc">mysql_refresh()</literal> C API function
+ now cause an implicit commit. See
+ <xref linkend="implicit-commit"/>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ <manual type="RESTORE"/>
+ <manual type="Windows"/>
+ <manual type="Vista"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39825"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Windows Vista, <literal role="stmt">RESTORE</literal> did not
+ correctly calculate the validity point from the backup stream.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39690"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The MySQL Backup <literal>backup_history</literal> log now
+ contains a <literal>backup_file_path</literal> column.
+ <literal>backup_file</literal> contains the basename and
+ <literal>backup_file_path</literal> contains the directory of
+ the image file pathname.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39598"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some MySQL Backup-related memory-use warnings detected by
+ Valgrind were corrected.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39089"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ MySQL Backup was not handling several errors.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38810"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">RESTORE</literal> crashed if a trigger and
+ an event had the same name.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36854"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Long error messages for <literal role="stmt">RESTORE</literal>
+ could be truncated.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34204"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If <literal role="stmt">BACKUP DATABASE</literal> and
+ <literal role="stmt">RESTORE</literal> were done in a session
+ with autocommit disabled, a later <literal role="stmt">DROP
+ TABLE</literal> or <literal role="stmt">RESTORE</literal> in the
+ same session failed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40126"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Windows builds were missing the MySQL Backup log tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37453"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30-ndb-6.2.17"/>
+ <version ver="5.1.29-ndb-6.3.19"/>
+ <version ver="5.1.30"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Dropping or creating an index on a partitioned table managed by
+ the <literal>InnoDB</literal> Plugin locked the table.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimization"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36896"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A server crash resulted from attempts at semi-join and
+ materialization optimizations for subqueries with a parent of
+ <literal>SELECT ... FROM DUAL</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="37891"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="func">SUM(DISTINCT)</literal> and
+ <literal role="func">AVG(DISTINCT)</literal> for an empty result
+ set in a subquery were not properly handled as being able to
+ return <literal>NULL</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37977"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server returned incorrect results for <literal>WHERE ... OR
+ ... GROUP BY</literal> queries against <literal>InnoDB</literal>
+ tables.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38072"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.74"/>
+ <version ver="5.1.31"/>
+ <version ver="6.0.7"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Queries with a <literal>HAVING</literal> clause could return a
+ spurious row.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Solaris"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39074"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.72"/>
+ <version ver="5.1.30"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some recent releases for Solaris 10 were built on Solaris 10 U5,
+ which included a new version of <filename>libnsl.so</filename>
+ that does not work on U4 or earlier. To correct this, Solaris 10
+ builds now are created on machines that do not have that
+ upgraded <filename>libnsl.so</filename>, so that they will work
+ on Solaris 10 installations both with and without the upgraded
+ <filename>libnsl.so</filename>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40360"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ With statement-based binary logging format and a transaction
+ isolation level of <literal role="isolevel">READ
+ COMMITTED</literal> or stricter, <literal>InnoDB</literal>
+ printed an error because statement-based logging might lead to
+ inconsistency between master and slave databases. However, this
+ error was printed even when binary logging was not enabled (in
+ which case, no such inconsistency can occur).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CHECK TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40053"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30"/>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>CHECK TABLE ... FOR UPGRADE</literal> statement did
+ not check for incompatible collation changes made in MySQL
+ 5.1.24. (This also affects <command>mysqlcheck</command> and
+ <command>mysql_upgrade</command>, which cause that statement to
+ be executed.)
+ </para>
+
+ <para>
+ Prior to this fix, a binary upgrade (performed without dumping
+ tables with <command>mysqldump</command> before the upgrade and
+ reloading the dump file after the upgrade) would corrupt tables.
+ After the fix, <literal>CHECK TABLE ... FOR UPGRADE</literal>
+ properly detects the problem and upgrades tables.
+ </para>
+
+ <para>
+ However, the fix is not backward compatible and can result in a
+ downgrading problem under these circumstances:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Perform a binary upgrade to a version of MySQL that includes
+ the fix.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Run <literal>CHECK TABLE ... FOR UPGRADE</literal> (or
+ <command>mysqlcheck</command> or
+ <command>mysql_upgrade</command>) to upgrade tables.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Perform a binary downgrade to a version of MySQL that does
+ not include the fix.
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ <para>
+ The solution is to dump tables with <command>mysqldump</command>
+ before the downgrade and reload the dump file after the
+ downgrade. Alternatively, drop and recreate affected indexes.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ALTER TABLE"/>
+ <manual type="ENUM"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="23113"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="stmt">ALTER TABLE</literal> for an
+ <literal role="type">ENUM</literal> column could change column
+ values.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40494"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.30"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A <literal>SELECT</literal> using a range
+ <literal>WHERE</literal> condition with an <literal>ORDER
+ BY</literal> on a partitioned table caused a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="prepared statements"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="32124"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Execution of a prepared statement that referred to a system
+ variable caused a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="RIGHT JOIN"/>
+ <manual type="stored procedures"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33811"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.74"/>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ For a stored procedure containing a <literal>SELECT * ... RIGHT
+ JOIN</literal> query, execution failed for the second call.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="mysqldumpslow"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34129"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <command>mysqldumpslow</command> did not aggregate times.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="EXPLAIN"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="34773"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>EXPLAIN EXTENDED</literal> evaluation of aggregate
+ functions that required a temporary table caused a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <bugs>
+ <fixes bugid="37129"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ MySQL support for adding collations using LDML specifications
+ did not support the <literal><i></literal> identity rule
+ that indicates one character sorts identically to another. The
+ <literal><i></literal> rule now is supported.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <bugs>
+ <fixes bugid="38636"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Binary distributions for Solaris, Linux, and Mac OS X now are
+ built with support for the <literal>pool-of-threads</literal>
+ value of <literal>thread_handling</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="INFORMATION_SCHEMA"/>
+ <manual type="MERGE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="35068"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Selecting from an <literal>INFORMATION_SCHEMA</literal> table
+ into an incorrectly defined <literal role="se">MERGE</literal>
+ table caused an assertion failure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="partitioning"/>
+ <manual type="errors"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36768"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Partitioned table checking sometimes returned a warning with an
+ error code of 0, making proper response to errors impossible.
+ The fix also renders the error message subject to translation in
+ non-English deployments.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ARCHIVE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37719"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Renaming an <literal role="se">ARCHIVE</literal> table to the
+ same name with different lettercase and then selecting from it
+ could cause a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="EXPLAIN"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37870"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Use of an uninitialized constant in
+ <literal role="stmt">EXPLAIN</literal> evaluation caused an
+ assertion failure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="subqueries"/>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37899"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ An incorrectly checked <literal>XOR</literal> subquery
+ optimization resulted in an assertion failure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="event scheduler"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38066"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The Event Scheduler no longer logs <quote>started in
+ thread</quote> or <quote>executed</quote> successfully messages
+ to the error log.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="query cache"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38551"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The server unnecessarily acquired a query cache mutex even with
+ the query cache disabled, resulting in a small performance
+ decrement.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39997"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The MySQL Backup message logger caused an assertion failure.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="INFORMATION_SCHEMA"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33649"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal>ROUTINES.DATA_TYPE</literal>,
+ <literal>REFERENTIAL_CONSTRAINTS.SPECIFIC_SCHEMA</literal>,
+ <literal>REFERENTIAL_CONSTRAINTS.SPECIFIC_NAME</literal>,
+ <literal>REFERENTIAL_CONSTRAINTS.PARAMETER_NAME</literal>,
+ <literal>REFERENTIAL_CONSTRAINTS.DATA_TYPE</literal> columns
+ were declared longer than the maximum allowed identifier length.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="optimizer"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="37851"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A query that could use one index to produce the desired ordering
+ and another index for range access with index condition pushdown
+ could cause a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="Solaris"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38477"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Solaris, a scheduling policy applied to the main server
+ process could be unintentionally overwritten in client-servicing
+ threads.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="INFORMATION_SCHEMA"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38918"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Performance of <literal>SELECT *</literal> retrievals from
+ <literal role="is">INFORMATION_SCHEMA.COLUMNS</literal> was
+ improved slightly.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="38941"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The fast mutex implementation was subject to excessive lock
+ contention.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="ALTER TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39372"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Use of the <literal>PACK_KEYS</literal> or
+ <literal>MAX_ROWS</literal> table option in
+ <literal role="stmt">ALTER TABLE</literal> should have triggered
+ table reconstruction but did not.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="views"/>
+ <manual type="binary log"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39040"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.74"/>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ With binary logging enabled <literal role="stmt">CREATE
+ VIEW</literal> was subject to possible buffer overwrite and a
+ server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="valgrind"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39102"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When built with Valgrind, the server failed to access tables
+ created with the <literal>DATA DIRECTORY</literal> or
+ <literal>INDEX DIRECTORY</literal> table option.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="INFORMATION_SCHEMA"/>
+ <manual type="SHOW"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="29153"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some <literal>SHOW</literal> statements and retrievals from the
+ <literal>INFORMATION_SCHEMA</literal>
+ <literal role="is">TRIGGERS</literal> and
+ <literal role="is">EVENTS</literal> tables used a temporary
+ table and incremented the
+ <literal>Created_tmp_disk_tables</literal> status variable, due
+ to the way that <literal>TEXT</literal> columns are handled. The
+ <literal>TRIGGERS.SQL_MODE</literal>,
+ <literal>TRIGGERS.DEFINER</literal>, and
+ <literal>EVENTS.SQL_MODE</literal> columns now are
+ <literal role="type">VARCHAR</literal> to avoid this problem.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ <manual type="PURGE BACKUP LOGS"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33364"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A new statement, <literal>PURGE BACKUP LOGS</literal>, enables
+ the contents of the MySQL Backup logs to be culled. See
+ <xref linkend="purge-backup-logs"/>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="RESTORE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="33574"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ If a <literal>TEMPORARY</literal> table existed with the same
+ name as a regular table, <literal role="stmt">BACKUP
+ DATABASE</literal> saved the temporary table, causing a
+ subsequent <literal role="stmt">RESTORE</literal> to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+ <fixes bugid="36279"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <command>mysql</command> client, when built with Visual
+ Studio 2005, did not display Japanese characters.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ <manual type="BACKUP DATABASE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36933"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Specifying a database name twice to <literal role="stmt">BACKUP
+ DATABASE</literal> caused a server crash. Now
+ <literal role="stmt">BACKUP DATABASE</literal> ignores duplicate
+ names.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ <manual type="BACKUP DATABASE"/>
+ <manual type="MyISAM"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39602"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Concurrent execution of <literal role="stmt">BACKUP
+ DATABASE</literal> and DML operations on
+ <literal role="se">MyISAM</literal> tables could produce a
+ deadlock.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ <manual type="backup_history_log"/>
+ <manual type="backup_progress_log"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40218"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The default value of the
+ <literal role="sysvar">backup_history_log</literal> and
+ <literal role="sysvar">backup_progress_log</literal> system
+ variables is <literal>ON</literal>, but explicitly setting them
+ to <literal>DEFAULT</literal> set them to
+ <literal>OFF</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ <manual type="backup_history_log_file"/>
+ <manual type="backup_progress_log_file"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40219"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The <literal role="sysvar">backup_history_log_file</literal> and
+ <literal role="sysvar">backup_progress_log_file</literal> system
+ variables were not settable at server startup. Now they are.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="InnoDB"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38883"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.31"/>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Use of <literal role="se">InnoDB</literal> monitoring
+ (<literal role="stmt" condition="show-engine">SHOW ENGINE INNODB
+ STATUS</literal> or one of the
+ <literal role="se">InnoDB</literal> Monitor tables) could cause
+ a server crash due to invalid access to a shared variable in a
+ concurrent environment.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ <manual type="Windows"/>
+ <manual type="locking"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="38342"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Windows, starting the server with the
+ <option>--external-locking=1</option> option caused
+ <literal role="stmt">BACKUP DATABASE</literal> to fail.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="CREATE TABLE"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="39591"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Creating a table with a comment of 62 characters or longer
+ caused a server crash.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <tags>
+ <manual type="replication"/>
+ </tags>
+
+ <versions>
+ <version ver="6.0.8"/>
+ </versions>
+
+ <message>
+
+ <para>
+ MySQL now supports an interface for semisynchronous replication:
+ A commit performed on the master side blocks before returning to
+ the session that performed the transaction until at least one
+ slave acknowleges that it has received and logged the events for
+ the transaction. Semisynchronous replication is implemented
+ through an optional plugin component. See
+ <xref linkend="replication-semisync"/>
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <manual type="MySQL Backup"/>
+ <manual type="valgrind"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="40480"/>
+ </bugs>
+
+ <versions>
+ <version ver="6.0.9"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Several MySQL Backup-related memory-use issues identified by
+ Valgrind were corrected.
+ </para>
+
+ </message>
+
+ </logentry>
+
</changelog>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r12714 - in trunk: . dynamic-docs/changelog | paul.dubois | 1 Dec |
