svn commit - mysqldoc@docsrva: r2474 - in trunk: . refman-5.1 refman-common

[paul]

Author: paul
Date: 2006-06-22 18:22:25 +0200 (Thu, 22 Jun 2006)
New Revision: 2474

Log:
 r11597@frost:  paul | 2006-06-22 11:22:03 -0500
 Document bugfixes:
 Bug#18175
 Bug#18396
 Bug#18895
 Bug#19225
 Bug#19580
 Bug#19727


Modified:
   trunk/
   trunk/refman-5.1/installing.xml
   trunk/refman-common/news-4.1.xml
   trunk/refman-common/news-5.0.xml
   trunk/refman-common/news-5.1.xml


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:10808
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:11595
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:7663
   + 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:10808
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:11597
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:7663

Modified: trunk/refman-5.1/installing.xml
===================================================================
--- trunk/refman-5.1/installing.xml	2006-06-22 14:53:47 UTC (rev 2473)
+++ trunk/refman-5.1/installing.xml	2006-06-22 16:22:25 UTC (rev 2474)
@@ -12139,6 +12139,24 @@
 
         <listitem>
           <para>
+            <emphasis role="bold">Incompatible change</emphasis>: For
+            <literal>utf8</literal> columns, the full-text parser
+            incorrectly considered several non-word punctuation and
+            whitespace characters as word characters, causing some
+            searches to return incorrect results. The fix involves a
+            change to the full-text parser in MySQL 5.1.12, so as of
+            5.1.12, any tables that have <literal>FULLTEXT</literal>
+            indexes on <literal>utf8</literal> columns must be repaired
+            with <literal>REPAIR TABLE</literal>:
+          </para>
+
+<programlisting>
+REPAIR TABLE <replaceable>tbl_name</replaceable> QUICK;
+</programlisting>
+        </listitem>
+
+        <listitem>
+          <para>
             <emphasis role="bold">Incompatible change</emphasis>: The
             structure of <literal>FULLTEXT</literal> indexes have been
             changed in MySQL 5.1.6. After upgrading to MySQL 5.1.6 or

Modified: trunk/refman-common/news-4.1.xml
===================================================================
--- trunk/refman-common/news-4.1.xml	2006-06-22 14:53:47 UTC (rev 2473)
+++ trunk/refman-common/news-4.1.xml	2006-06-22 16:22:25 UTC (rev 2474)
@@ -338,6 +338,23 @@
 
       <listitem>
         <para>
+          <literal>InnoDB</literal> unlocked its data directory before
+          committing a transaction, potentially resulting in
+          non-recoverable tables if a server crash occurred before the
+          commit. (Bug #19727)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          Multiple-table <literal>DELETE</literal> statements containing
+          a subquery that selected from one of the tables being modified
+          caused a server crash. (Bug #19225)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           The <literal>ARCHIVE</literal> storage engine does not support
           <literal>TRUNCATE TABLE</literal>, but the server was not
           returning an appropriate error when truncation of an

Modified: trunk/refman-common/news-5.0.xml
===================================================================
--- trunk/refman-common/news-5.0.xml	2006-06-22 14:53:47 UTC (rev 2473)
+++ trunk/refman-common/news-5.0.xml	2006-06-22 16:22:25 UTC (rev 2474)
@@ -564,6 +564,38 @@
 
       <listitem>
         <para>
+          <literal>BIT</literal> columns in a table could cause joins
+          that use the table to fail. (Bug #18895)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          A <literal>UNION</literal> over more than 128
+          <literal>SELECT</literal> statements that use an aggregate
+          function failed. (Bug #18175)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal>InnoDB</literal> unlocked its data directory before
+          committing a transaction, potentially resulting in
+          non-recoverable tables if a server crash occurred before the
+          commit. (Bug #19727)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          Multiple-table <literal>DELETE</literal> statements containing
+          a subquery that selected from one of the tables being modified
+          caused a server crash. (Bug #19225)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           With settings of <literal>read_buffer_size</literal> &gt;= 2G
           and <literal>read_rnd_buffer_size</literal> &gt;=2G,
           <literal>LOAD DATA INFILE</literal> failed with no error

Modified: trunk/refman-common/news-5.1.xml
===================================================================
--- trunk/refman-common/news-5.1.xml	2006-06-22 14:53:47 UTC (rev 2473)
+++ trunk/refman-common/news-5.1.xml	2006-06-22 16:22:25 UTC (rev 2474)
@@ -174,17 +174,42 @@
       Bugs fixed:
     </para>
 
+    <remark role="note">
+      Leave any imcompatible fixes first in the list.
+    </remark>
+
     <itemizedlist>
-      
+
       <listitem>
         <para>
+          <emphasis role="bold">Incompatible change</emphasis>: For
+          <literal>utf8</literal> columns, the full-text parser
+          incorrectly considered several non-word punctuation and
+          whitespace characters as word characters, causing some
+          searches to return incorrect results. (Bug #19580)
+        </para>
+
+        <para>
+          The fix involves a change to the full-text parser, so any
+          tables that have <literal>FULLTEXT</literal> indexes on
+          <literal>utf8</literal> columns must be repaired with
+          <literal>REPAIR TABLE</literal>:
+        </para>
+
+<programlisting>
+REPAIR TABLE <replaceable>tbl_name</replaceable> QUICK;
+</programlisting>
+      </listitem>
+
+      <listitem>
+        <para>
           <literal>NDB Cluster</literal>: <literal>TEXT</literal>
           columns in Cluster tables having both an explicit primary key
           and a unque key were not correctly updated by
           <literal>REPLACE</literal> statements. (Bug #19906)
         </para>
       </listitem>
-      
+
       <listitem>
         <para>
           <literal>NDB Cluster</literal>: Running out of DataMemory
@@ -438,6 +463,46 @@
 
       <listitem>
         <para>
+          Identifiers could not contain bytes with a value of 255,
+          though that should be allowed as of the identifier-encoding
+          changes made in MySQL 5.1.6. (Bug #12982)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal>BIT</literal> columns in a table could cause joins
+          that use the table to fail. (Bug #18895)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          A <literal>UNION</literal> over more than 128
+          <literal>SELECT</literal> statements that use an aggregate
+          function failed. (Bug #18175)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal>InnoDB</literal> unlocked its data directory before
+          committing a transaction, potentially resulting in
+          non-recoverable tables if a server crash occurred before the
+          commit. (Bug #19727)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          Multiple-table <literal>DELETE</literal> statements containing
+          a subquery that selected from one of the tables being modified
+          caused a server crash. (Bug #19225)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           With settings of <literal>read_buffer_size</literal> &gt;= 2G
           and <literal>read_rnd_buffer_size</literal> &gt;=2G,
           <literal>LOAD DATA INFILE</literal> failed with no error
@@ -2593,7 +2658,7 @@
           It was possible to create a
           <literal>RANGE</literal>-partitioned table with a partition
           defined using the clause <literal>VALUES LESS THAN
-            (NULL)</literal>, even though such a partition could never
+          (NULL)</literal>, even though such a partition could never
           contain any values whatsoever. (Bug #18752)
         </para>
       </listitem>
@@ -4389,7 +4454,7 @@
       <listitem>
         <para>
           Naming a partition using the characters
-          <emphasis role="bold">Ç</emphasis> or 
+          <emphasis role="bold">Ç</emphasis> or
           <emphasis role="bold">ç</emphasis>
(<quote>c-cedilla</quote>;
           Unicode <literal>00C7</literal> or
<literal>00E7</literal>)
           made unreadable the table containing the partition. (Bug
@@ -6613,8 +6678,7 @@
           stored as separate tables in different locations, but from the
           user point of view, the partitioned table is still a single
           table. See <xref linkend="partitioning"/>, for further
-          information on this functionality. (Author: Mikael
-          Ronström)
+          information on this functionality. (Author: Mikael Ronström)
         </para>
       </listitem>
 
@@ -6891,9 +6955,9 @@
         <para>
           When two threads competed for the same table, a deadlock could
           occur if one thread also had a lock on another table through
-          <literal>LOCK TABLES</literal> and the thread was attempting to
-          remove the table in some manner while the other thread tried
-          to place locks on both tables. (Bug #10600)
+          <literal>LOCK TABLES</literal> and the thread was attempting
+          to remove the table in some manner while the other thread
+          tried to place locks on both tables. (Bug #10600)
         </para>
       </listitem>