svn commit - mysqldoc@docsrva: r12667 - trunk/dynamic-docs/changelog

[jon]

Author: jstephens
Date: 2008-11-26 15:53:24 +0100 (Wed, 26 Nov 2008)
New Revision: 12667

Log:

Documented fix for Partitioning Bug#40954.



Modified:
   trunk/dynamic-docs/changelog/mysqld-1.xml


Modified: trunk/dynamic-docs/changelog/mysqld-1.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-1.xml	2008-11-26 14:36:21 UTC (rev 12666)
+++ trunk/dynamic-docs/changelog/mysqld-1.xml	2008-11-26 14:53:24 UTC (rev 12667)
Changed blocks: 5, Lines Added: 125, Lines Deleted: 8; 5051 bytes

@@ -9,6 +9,122 @@
   <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"/>
+    </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&apos;s <literal>WHERE</literal> clause referenced
+            an indexed column that was also in the partitioning key.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            The query&apos;s <literal>WHERE</literal> clause included a
+            value found in the partition.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            The query&apos;s <literal>WHERE</literal> clause used the
+            <literal>&lt;</literal> or <literal>&lt;&gt;</literal>
+            operators to compare with the indexed column&apos;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&apos;s partitioning key:
+      </para>
+
+      <orderedlist>
+
+        <listitem>
+          <para>
+<programlisting>            
+SELECT * FROM <replaceable>table</replaceable> WHERE a &lt; <replaceable>constant</replaceable> ORDER BY a;
+</programlisting>
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+<programlisting>            
+SELECT * FROM <replaceable>table</replaceable> WHERE a &lt;&gt; <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()"/>

@@ -23353,8 +23469,8 @@
 
       <para>
         Memory-allocation failures for attempts to set
-        <literal role="sysvar">key_buffer_size</literal> to large values could result
-        in a server crash.
+        <literal role="sysvar">key_buffer_size</literal> to large values
+        could result in a server crash.
       </para>
 
     </message>

@@ -25690,9 +25806,9 @@
         <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.
+        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>

@@ -29531,7 +29647,8 @@
       <para>
         On 64-bit systems, assigning values of 2
         <superscript>63</superscript> &minus; 1 or larger to
-        <literal role="sysvar">key_buffer_size</literal> caused memory overruns.
+        <literal role="sysvar">key_buffer_size</literal> caused memory
+        overruns.
       </para>
 
     </message>

@@ -32631,8 +32748,8 @@
         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.
+        <literal role="sysvar">general_log_file</literal> system
+        variables, which can be changed at runtime.
       </para>
 
       <para>