Author: jstephens
Date: 2011-01-26 12:38:07 +0100 (Wed, 26 Jan 2011)
New Revision: 24888
Log:
Changelog entries/Cluster bugfixes:
BUG#59437, BUG#59496, BUG#59501,
BUG#59502, BUG#59517, BUG#59519
Modified:
trunk/dynamic-docs/changelog/mysqld-2.xml
Modified: trunk/dynamic-docs/changelog/mysqld-2.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-2.xml 2011-01-26 04:21:05 UTC (rev 24887)
+++ trunk/dynamic-docs/changelog/mysqld-2.xml 2011-01-26 11:38:07 UTC (rev 24888)
Changed blocks: 1, Lines Added: 214, Lines Deleted: 0; 5626 bytes
@@ -9,7 +9,221 @@
<logentry entrytype="bug">
<tags>
+ <highlight type="diskdata"/>
+ <manual type="DROP LOGFILE GROUP"/>
+ <manual type="file I/O"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="59502"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.51-ndb-6.3.40"/>
+ <version ver="5.1.51-ndb-7.0.21"/>
+ <version ver="5.1.51-ndb-7.1.10"/>
+ </versions>
+
+ <message>
+
+ <para>
+ In certain cases, a race condition could occur when
+ <literal role="stmt">DROP LOGFILE GROUP</literal> removed the
+ logfile group while a read or write of one of the effected files
+ was in progress, which in turn could lead to a crash of the data
+ node.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="diskdata"/>
+ <manual type="DROP TABLESPACE"/>
+ <manual type="LCP"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="59501"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.51-ndb-6.3.40"/>
+ <version ver="5.1.51-ndb-7.0.21"/>
+ <version ver="5.1.51-ndb-7.1.10"/>
+ </versions>
+
+ <message>
+
+ <para>
+ A race condition could sometimes be created when
+ <literal role="stmt">DROP TABLESPACE</literal> was run
+ concurrently with a local checkpoint; this could in turn lead to
+ a crash of the data node.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
<highlight type="cluster"/>
+ <manual type="ordered indexes"/>
+ <manual type="unique indexes"/>
+ <manual type="ha_ndbcluster::set_rec_per_key()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="59519"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.51-ndb-7.0.22"/>
+ <version ver="5.1.51-ndb-7.1.11"/>
+ </versions>
+
+ <message>
+
+ <para>
+ <literal role="se">NDB</literal> sometimes treated a simple (not
+ unique) ordered index as unique.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ranges"/>
+ <manual type="ha_ndbcluster::records_in_range()"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="59517"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.51-ndb-7.0.22"/>
+ <version ver="5.1.51-ndb-7.1.11"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The logic used in determining whether to collapse a range to a
+ simple equality was faulty. In certain cases, this could cause a
+ primary key lookup to be used, thus returning only a single row,
+ even though multiple records matched the range.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="transactions"/>
+ <manual type="concurrent operations"/>
+ <manual type="READ_COMMITTED"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="59496"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.51-ndb-6.3.40"/>
+ <version ver="5.1.51-ndb-7.0.21"/>
+ <version ver="5.1.51-ndb-7.1.10"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Two related problems could occur with read-committed scans made
+ in parallel with transactions combining multiple (concurrent)
+ operations:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ When committing a multiple-operation transaction that
+ contained concurrent insert and update operations on the
+ same record, the commit arrived first for the insert and
+ then for the update. If a read-committed scan arrived
+ between these operations, it could thus read incorrect data;
+ in addition, if the scan read variable-size data, it could
+ cause the data node to fail.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ When rolling back a multiple-operation transaction having
+ concurrent delete and insert operations on the same record,
+ the abort arrived first for the delete operation, and then
+ for the insert. If a read-committed scan arrived between the
+ delete and the insert, it could incorrectly assume that the
+ record should not be returned (in other words, the scan
+ treated the insert as though it had not yet been committed).
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
+ <manual type="ndb_mgmd"/>
+ <manual type="Windows"/>
+ <manual type="SHUTDOWN"/>
+ <manual type="--nodaemon"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="59437"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.51-ndb-7.0.21"/>
+ <version ver="5.1.51-ndb-7.1.10"/>
+ </versions>
+
+ <message>
+
+ <para>
+ On Windows platforms, issuing a <literal>SHUTDOWN</literal>
+ command in the <command>ndb_mgm</command> client caused
+ management processes that had been started with the
+ <option role="ndb_mgmd">--nodaemon</option> option to exit
+ abnormally.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="cluster"/>
<manual type="condition pushdown"/>
</tags>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r24888 - trunk/dynamic-docs/changelog | jon.stephens | 26 Jan |
