MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:jon Date:November 6 2007 4:29pm
Subject:svn commit - mysqldoc@docsrva: r8554 - trunk/dynamic-docs/changelog
View as plain text  
Author: jstephens
Date: 2007-11-06 17:29:54 +0100 (Tue, 06 Nov 2007)
New Revision: 8554

Log:

Consolidated some more redundant changelog entries.



Modified:
   trunk/dynamic-docs/changelog/dupes.txt
   trunk/dynamic-docs/changelog/mysqld.xml


Modified: trunk/dynamic-docs/changelog/dupes.txt
===================================================================
--- trunk/dynamic-docs/changelog/dupes.txt	2007-11-06 14:46:49 UTC (rev 8553)
+++ trunk/dynamic-docs/changelog/dupes.txt	2007-11-06 16:29:54 UTC (rev 8554)
Changed blocks: 2, Lines Added: 24, Lines Deleted: 24; 736 bytes

@@ -113,29 +113,29 @@
 14897x
 14940x
 15098x
-15101
-15223
-15303
-15347
-15408
-15650
-15685
-15846
-15921
-15991
-16201
-16266
-16377
-16382
-16387
-16421
+15101x
+15223x
+15303x
+15347x
+15408x
+15650x
+15685x
+15846x
+15921x
+15991x
+16201x
+16266x
+16377x
+16382x
+16387x
+16421x
 16520x
-16539
-16561
-16582
-16614
-16674
-16695
+16539x
+16561x
+16582x
+16614x
+16674x
+16695x
 16861
 17047
 17208

@@ -146,13 +146,13 @@
 17667
 17671
 17810
-17857
+17857x
 17876
 17926
 18091x
 18283
 18298
-18359
+18359x
 18361
 18385
 18386


Modified: trunk/dynamic-docs/changelog/mysqld.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld.xml	2007-11-06 14:46:49 UTC (rev 8553)
+++ trunk/dynamic-docs/changelog/mysqld.xml	2007-11-06 16:29:54 UTC (rev 8554)
Changed blocks: 54, Lines Added: 224, Lines Deleted: 623; 27856 bytes

@@ -6129,6 +6129,7 @@
     <tags>
       <manual type="RENAME TABLE"/>
       <manual type="innodb_file_per_table"/>
+      <manual type="InnoDB"/>
     </tags>
 
     <bugs>

@@ -6137,15 +6138,16 @@
 
     <versions>
       <version ver="4.1.17"/>
+      <version ver="5.0.19"/>
     </versions>
 
     <message>
 
       <para>
-        Performing a <literal>RENAME TABLE</literal> on an InnoDB table
-        when the server is started with the
-        <option>--innodb_file_per_table</option> option and the data
-        directory is a symlink caused a server crash.
+        Performing a <literal>RENAME TABLE</literal> on an
+        <literal>InnoDB</literal> table when the server was started with
+        the <option>--innodb_file_per_table</option> option and the data
+        directory was a symlink caused a server crash.
       </para>
 
     </message>

@@ -11681,36 +11683,6 @@
   <logentry entrytype="bug">
 
     <tags>
-      <manual type="LIKE"/>
-      <manual type="character sets"/>
-    </tags>
-
-    <bugs>
-      <fixes bugid="18359"/>
-      <fixes bugid="16674"/>
-    </bugs>
-
-    <versions>
-      <version ver="4.1.21"/>
-    </versions>
-
-    <message>
-
-      <para>
-        The length of the pattern string prefix for
-        <literal>LIKE</literal> operations was calculated incorrectly
-        for multi-byte character sets. As a result, the scanned range
-        was wider than necessary if the prefix contained any multi-byte
-        characters.
-      </para>
-
-    </message>
-
-  </logentry>
-
-  <logentry entrytype="bug">
-
-    <tags>
       <highlight type="cluster"/>
       <manual type="CREATE LOGFILE GROUP"/>
       <manual type="ENGINE"/>

@@ -13728,8 +13700,9 @@
     </bugs>
 
     <versions>
-      <version ver="5.1.8"/>
+      <version ver="4.1.19"/>
       <version ver="5.0.20"/>
+      <version ver="5.1.8"/>
     </versions>
 
     <message>

@@ -16052,7 +16025,7 @@
     </tags>
 
     <bugs>
-      <fixes bugid="16614"/>
+      <fixes bugid="11551"/>
     </bugs>
 
     <versions>

@@ -26294,11 +26267,16 @@
     <message>
 
       <para>
-        Certain subqueries where the inner query is the result of a
-        aggregate function would return different results on MySQL 5.0
-        than on MySQL 4.1.
+        Certain subqueries where the inner query was the result of a
+        aggregate function would return different results with MySQL
+        &current-series; than with MySQL 4.1.
       </para>
 
+      <para>
+        Subselects could also return wrong results when the query cache
+        and grouping were involved.
+      </para>
+
     </message>
 
   </logentry>

@@ -34721,7 +34699,7 @@
 
   </logentry>
 
-  <logentry entrytype="feature">
+  <logentry entrytype="bug">
 
     <tags>
       <manual type="zlib"/>

@@ -34733,11 +34711,21 @@
 
     <versions>
       <version ver="5.0.17"/>
+      <version ver="4.1.18"/>
     </versions>
 
-    <message>
+    <message ver="4.1.18">
 
       <para>
+        RPM packages had an incorrect <literal>zlib</literal>
+        dependency.
+      </para>
+
+    </message>
+
+    <message ver="5.0.17">
+
+      <para>
         The original Linux RPM packages (5.0.17-0) had an issue with a
         <literal>zlib</literal> dependency that would result in an error
         during an install or upgrade. They were replaced by new

@@ -45076,28 +45064,6 @@
   <logentry entrytype="bug">
 
     <bugs>
-      <fixes bugid="15347"/>
-    </bugs>
-
-    <versions>
-      <version ver="5.1.6"/>
-      <version ver="5.0.19"/>
-    </versions>
-
-    <message>
-
-      <para>
-        Subselect could return wrong results when records cache and
-        grouping was involved.
-      </para>
-
-    </message>
-
-  </logentry>
-
-  <logentry entrytype="bug">
-
-    <bugs>
       <fixes bugid="11927"/>
     </bugs>
 

@@ -47625,15 +47591,16 @@
     </bugs>
 
     <versions>
+      <version ver="4.1.19"/>
       <version ver="5.0.19"/>
     </versions>
 
     <message>
 
       <para>
-        Server crash when dropping <literal>InnoDB</literal> constraints
-        named <literal>
-        <replaceable>TABLENAME</replaceable>_ibfk_0</literal>.
+        Dropping <literal>InnoDB</literal> constraints named
+        <literal><replaceable>tbl_name</replaceable>_ibfk_0</literal>
+        could crash the server.
       </para>
 
     </message>

@@ -49107,9 +49074,10 @@
 
     <versions>
       <version ver="5.0.20"/>
+      <version ver="5.1.9"/>
     </versions>
 
-    <message>
+    <message ver="5.0.20">
 
       <para>
         Triggers created in MySQL 5.0.16 and earlier could not be

@@ -49118,6 +49086,15 @@
 
     </message>
 
+    <message ver="5.1.9">
+
+      <para>
+        Triggers created in one version of the server could not be
+        dropped after upgrading to a newer version.
+      </para>
+
+    </message>
+
   </logentry>
 
   <logentry entrytype="bug">

@@ -53364,34 +53341,6 @@
   <logentry entrytype="bug">
 
     <tags>
-      <manual type="glibc"/>
-    </tags>
-
-    <bugs>
-      <fixes bugid="16539"/>
-    </bugs>
-
-    <versions>
-      <version ver="4.1.19"/>
-    </versions>
-
-    <message>
-
-      <para>
-        <literal>MySQL-shared-compat-4.1.15-0.i386.rpm</literal>,
-        <literal>MySQL-shared-compat-4.1.16-0.i386.rpm</literal>, and
-        <literal>MySQL-shared-compat-4.1.18-0.i386.rpm</literal>
-        incorrectly depended on <literal>glibc</literal> 2.3 and could
-        not be installed on a <literal>glibc</literal> 2.2 system.
-      </para>
-
-    </message>
-
-  </logentry>
-
-  <logentry entrytype="bug">
-
-    <tags>
       <highlight type="cluster"/>
       <manual type="replication"/>
     </tags>

@@ -55886,9 +55835,11 @@
 
     <versions>
       <version ver="5.0.17"/>
+      <version ver="5.0.20"/>
+      <version ver="5.1.8"/>
     </versions>
 
-    <message>
+    <message ver="5.0.17">
 
       <para>
         The syntax for <literal>CREATE TRIGGER</literal> now includes a

@@ -55897,26 +55848,38 @@
         <xref linkend="create-trigger"/>, for more information.
       </para>
 
-      <para>
-        <emphasis role="bold">Known issue</emphasis>: If you attempt to
-        replicate from a master server older than MySQL 5.0.17 to a
-        slave running MySQL 5.0.17 through 5.0.19, replication of
-        <literal>CREATE TRIGGER</literal> statements fails on the slave
-        with a <literal>Definer not fully qualified</literal> error. A
-        workaround is to create triggers on the master using a
-        version-specific comment embedded in each <literal>CREATE
-        TRIGGER</literal> statement:
-      </para>
+      <formalpara>
 
+        <title>Known issue</title>
+        <para>
+          If you attempt to replicate from a master server older than
+          MySQL 5.0.17 to a slave running MySQL 5.0.17 through 5.0.19,
+          replication of <literal>CREATE TRIGGER</literal> statements
+          fails on the slave with a <errortext>Definer not fully
+          qualified error</errortext>. A workaround is to create
+          triggers on the master using a version-specific comment
+          embedded in each <literal>CREATE TRIGGER</literal> statement:
 <programlisting>
 CREATE /*!50017 DEFINER = 'root'@'localhost' */ TRIGGER ... ;
 </programlisting>
+          <literal>CREATE TRIGGER</literal> statements written this way
+          will replicate to newer slaves, which pick up the
+          <literal>DEFINER</literal> clause from the comment and execute
+          successfully.
+        </para>
 
+      </formalpara>
+
+    </message>
+
+    <message>
+
       <para>
-        <literal>CREATE TRIGGER</literal> statements written this way
-        will replicate to newer slaves, which pick up the
-        <literal>DEFINER</literal> clause from the comment and execute
-        successfully.
+        Triggers from older servers that included no
+        <literal>DEFINER</literal> clause in the trigger definition now
+        execute with the privileges of the invoker (which on the slave
+        is the slave SQL thread). Previously, replication slaves could
+        not replicate such triggers.
       </para>
 
     </message>

@@ -57543,33 +57506,6 @@
 
   </logentry>
 
-  <logentry entrytype="bug">
-
-    <tags>
-      <highlight type="cluster"/>
-      <manual type="transactions"/>
-    </tags>
-
-    <bugs>
-      <fixes bugid="15685"/>
-    </bugs>
-
-    <versions>
-      <version ver="4.1.17"/>
-    </versions>
-
-    <message>
-
-      <para>
-        If an abort by the Transaction Coordinator timed out, the abort
-        condition was incorrectly handled, causing the transacviton
-        record to be released prematurely.
-      </para>
-
-    </message>
-
-  </logentry>
-
   <logentry entrytype="feature">
 
     <tags>

@@ -61847,6 +61783,7 @@
     </bugs>
 
     <versions>
+      <version ver="5.0.20"/>
       <version ver="5.1.8"/>
     </versions>
 

@@ -64702,6 +64639,7 @@
     </bugs>
 
     <versions>
+      <version ver="4.1.17"/>
       <version ver="5.0.18"/>
     </versions>
 

@@ -69333,6 +69271,7 @@
     </bugs>
 
     <versions>
+      <version ver="5.0.25"/>
       <version ver="5.1.12"/>
     </versions>
 

@@ -73466,14 +73405,15 @@
     </bugs>
 
     <versions>
+      <version ver="4.1.19"/>
       <version ver="5.0.19"/>
     </versions>
 
     <message>
 
       <para>
-        Corrected race condition when dropping the adaptive hash index
-        for a B-tree page in <literal>InnoDB</literal>.
+        A race condition could occur when dropping the adaptive hash
+        index for a B-tree page in <literal>InnoDB</literal>.
       </para>
 
     </message>

@@ -76256,27 +76196,6 @@
 
   <logentry entrytype="bug">
 
-    <bugs>
-      <fixes bugid="16387"/>
-    </bugs>
-
-    <versions>
-      <version ver="4.1.19"/>
-    </versions>
-
-    <message>
-
-      <para>
-        Server crash when dropping InnoDB constraints named <literal>
-        <replaceable>TABLENAME</replaceable>_ibfk_0</literal>.
-      </para>
-
-    </message>
-
-  </logentry>
-
-  <logentry entrytype="bug">
-
     <tags>
       <highlight type="cluster"/>
       <manual type="replication"/>

@@ -80366,35 +80285,6 @@
   <logentry entrytype="bug">
 
     <tags>
-      <manual type="InnoDB"/>
-      <manual type="RENAME TABLE"/>
-      <manual type="innodb_file_per_table"/>
-    </tags>
-
-    <bugs>
-      <fixes bugid="15991"/>
-    </bugs>
-
-    <versions>
-      <version ver="5.0.19"/>
-    </versions>
-
-    <message>
-
-      <para>
-        Performing a <literal>RENAME TABLE</literal> on an
-        <literal>InnoDB</literal> table when the server is started with
-        the <option>--innodb_file_per_table</option> option and the data
-        directory is a symlink caused a server crash.
-      </para>
-
-    </message>
-
-  </logentry>
-
-  <logentry entrytype="bug">
-
-    <tags>
       <manual type="CSV"/>
     </tags>
 

@@ -81329,7 +81219,8 @@
     <message>
 
       <para>
-        Patch reverted.
+        A patch fixing the omission of leading zeros in dates in MySQL
+        4.1.21 was reverted.
       </para>
 
     </message>

@@ -81534,12 +81425,7 @@
 
     <tags>
       <highlight type="incompatiblechange"/>
-      <manual type="mysqldump"/>
       <manual type="partitioning"/>
-      <manual type="SELECT INTO"/>
-      <manual type="CREATE TABLE"/>
-      <manual type="LOAD DATA"/>
-      <manual type="mysqld"/>
     </tags>
 
     <bugs>

@@ -81548,7 +81434,7 @@
     </bugs>
 
     <versions>
-      <version ver="5.1.6"/>
+      <version ver="5.1.7"/>
     </versions>
 
     <message>

@@ -81556,21 +81442,55 @@
       <para>
         Due to a change in the naming scheme for partitioning and
         subpartitioning files, it is not possible for the server to read
-        partitioned tables created in previous MySQL versions. A
-        suggested workaround is (1) to create a non-partitioned table
-        with the same table schema using a standard <literal>CREATE
-        TABLE</literal> statement (that is, with no partitioning
-        clauses) and then (2) to issue a <literal>SELECT INTO</literal>
-        to copy the data into the non-partitioned table before the
-        upgrade; following the upgrade, you can partition the new table
-        using <literal>ALTER TABLE ... PARTITION BY ...</literal>.
-        Alternatively, you can dump the table using
-        <command>mysqldump</command> prior to upgrading and reload it
-        afterwards with <literal>LOAD DATA</literal>. In either case,
-        you should drop the pre-5.1.6 partitioned tables before
-        upgrading to 5.1.6 or later.
+        partitioned tables created in previous MySQL versions.
+        Attempting to read pre-5.1.6 partitioned tables with a MySQL
+        5.1.7 or later server now generates a suitable warning message.
       </para>
 
+      <para>
+        Two possible workarounds are:
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              <orderedlist>
+
+                <listitem>
+                  <para>
+                    Create a non-partitioned table with the same table
+                    schema using a standard <literal>CREATE
+                    TABLE</literal> statement (that is, with no
+                    partitioning clauses)
+                  </para>
+                </listitem>
+
+                <listitem>
+                  <para>
+                    Issue a <literal>SELECT INTO</literal> to copy the
+                    data into the non-partitioned table before the
+                    upgrade
+                  </para>
+                </listitem>
+
+              </orderedlist>
+              Following the upgrade, you can partition the new table
+              using <literal>ALTER TABLE ... PARTITION BY ...</literal>.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              Alternatively, you can dump the table using
+              <command>mysqldump</command> prior to upgrading and reload
+              it afterwards with <literal>LOAD DATA</literal>.
+            </para>
+          </listitem>
+
+        </itemizedlist>
+        In either case, you should drop the pre-5.1.6 partitioned tables
+        before upgrading to 5.1.6 or later.
+      </para>
+
       <important>
         <para>
           If any partitioned tables that were created prior to MySQL

@@ -81579,9 +81499,28 @@
           <literal>INFORMATION_SCHEMA.PARTITIONS</literal> table, nor
           will you be able to drop those tables or the database or
           databases in which they are located. In this event, you must:
-          (1) shut down <command>mysqld</command>; (2) manually delete
-          the table, partition, and (if any) subpartition files; and
-          then (3) restart the MySQL Server.
+          <orderedlist>
+
+            <listitem>
+              <para>
+                Shut down <command>mysqld</command>
+              </para>
+            </listitem>
+
+            <listitem>
+              <para>
+                Manually delete the table, partition, and (if any)
+                subpartition files
+              </para>
+            </listitem>
+
+            <listitem>
+              <para>
+                Restart the MySQL Server
+              </para>
+            </listitem>
+
+          </orderedlist>
         </para>
       </important>
 

@@ -82891,37 +82830,6 @@
 
   </logentry>
 
-  <logentry entrytype="feature">
-
-    <tags>
-      <manual type="partitioning"/>
-    </tags>
-
-    <bugs>
-      <fixes bugid="16695"/>
-    </bugs>
-
-    <versions>
-      <version ver="5.1.7"/>
-    </versions>
-
-    <message>
-
-      <para>
-        Attempting to read pre-5.1.6 partitioned tables with a MySQL
-        5.1.7 (or later) server now generates a suitable warning
-        message.
-      </para>
-
-      <para>
-        For additional information about this issue, see
-        <xref linkend="news-5-1-6"/>.
-      </para>
-
-    </message>
-
-  </logentry>
-
   <logentry entrytype="bug">
 
     <bugs>

@@ -84801,6 +84709,7 @@
     </bugs>
 
     <versions>
+      <version ver="5.0.19"/>
       <version ver="5.1.7"/>
     </versions>
 

@@ -85131,32 +85040,6 @@
   <logentry entrytype="bug">
 
     <tags>
-      <manual type="GROUP BY"/>
-      <manual type="SELECT"/>
-    </tags>
-
-    <bugs>
-      <fixes bugid="16382"/>
-    </bugs>
-
-    <versions>
-      <version ver="5.0.19"/>
-    </versions>
-
-    <message>
-
-      <para>
-        <literal>SELECT</literal> with <literal>GROUP BY</literal> on a
-        view can cause a server crash.
-      </para>
-
-    </message>
-
-  </logentry>
-
-  <logentry entrytype="bug">
-
-    <tags>
       <highlight type="cluster"/>
       <manual type="DELETE FROM TABLE"/>
     </tags>

@@ -90651,9 +90534,10 @@
     </bugs>
 
     <versions>
-      <version ver="5.0.33"/>
-      <version ver="5.0.30"/>
       <version ver="4.1.22"/>
+      <version ver="5.0.30"/>
+      <version ver="5.0.33"/>
+      <version ver="5.1.12"/>
     </versions>
 
     <message>

@@ -90665,6 +90549,16 @@
 
     </message>
 
+    <message ver="5.1.12">
+
+      <para>
+        A problem with takeover during a system restart caused ordered
+        indexes to be rebuilt incorrectly. This also adversely affected
+        MySQL Cluster Replication.
+      </para>
+
+    </message>
+
   </logentry>
 
   <logentry entrytype="bug">

@@ -95941,37 +95835,6 @@
   <logentry entrytype="bug">
 
     <tags>
-      <manual type="replication"/>
-      <manual type="DEFINER"/>
-      <manual type="triggers"/>
-    </tags>
-
-    <bugs>
-      <fixes bugid="16266"/>
-    </bugs>
-
-    <versions>
-      <version ver="5.1.8"/>
-      <version ver="5.0.20"/>
-    </versions>
-
-    <message>
-
-      <para>
-        Replication slaves could not replicate triggers from older
-        servers that included no <literal>DEFINER</literal> clause in
-        the trigger definition. Now the trigger executes with the
-        privileges of the invoker (which on the slave is the slave SQL
-        thread).
-      </para>
-
-    </message>
-
-  </logentry>
-
-  <logentry entrytype="bug">
-
-    <tags>
       <manual type="SHOW TABLES FROM"/>
     </tags>
 

@@ -98141,6 +98004,7 @@
     </bugs>
 
     <versions>
+      <version ver="5.0.25"/>
       <version ver="5.1.12"/>
     </versions>
 

@@ -98149,9 +98013,9 @@
       <para>
         The
         <literal>index_merge</literal>/<literal>Intersection</literal>
-        optimizer could have a memory overrun when the number of table
-        columns covered by an index is sufficiently large, possibly
-        resulting in a server crash.
+        optimizer could experience a memory overrun when the number of
+        table columns covered by an index was sufficiently large,
+        possibly resulting in a server crash.
       </para>
 
     </message>

@@ -99474,9 +99338,10 @@
 
     <versions>
       <version ver="5.1.7"/>
+      <version ver="5.1.8"/>
     </versions>
 
-    <message>
+    <message ver="5.1.7">
 
       <para>
         All subpartitions within a given partitioned table are now

@@ -99485,6 +99350,15 @@
 
     </message>
 
+    <message ver="5.1.8">
+
+      <para>
+        Names of subpartitions must now be unique for an entire table,
+        and not merely within the same partition.
+      </para>
+
+    </message>
+
   </logentry>
 
   <logentry entrytype="bug">

@@ -105088,27 +104962,6 @@
 
   </logentry>
 
-  <logentry entrytype="bug">
-
-    <bugs>
-      <fixes bugid="16582"/>
-    </bugs>
-
-    <versions>
-      <version ver="4.1.19"/>
-    </versions>
-
-    <message>
-
-      <para>
-        Corrected race condition when dropping the adaptive hash index
-        for a B-tree page in InnoDB.
-      </para>
-
-    </message>
-
-  </logentry>
-
   <logentry entrytype="feature">
 
     <tags>

@@ -105448,31 +105301,6 @@
   <logentry entrytype="bug">
 
     <tags>
-      <manual type="perror"/>
-    </tags>
-
-    <bugs>
-      <fixes bugid="16561"/>
-    </bugs>
-
-    <versions>
-      <version ver="5.0.25"/>
-    </versions>
-
-    <message>
-
-      <para>
-        <command>perror</command> did not properly report NDB error
-        codes.
-      </para>
-
-    </message>
-
-  </logentry>
-
-  <logentry entrytype="bug">
-
-    <tags>
       <manual type="triggers"/>
     </tags>
 

@@ -110670,32 +110498,6 @@
   <logentry entrytype="bug">
 
     <tags>
-      <manual type="glibc"/>
-    </tags>
-
-    <bugs>
-      <fixes bugid="16539"/>
-    </bugs>
-
-    <versions>
-      <version ver="5.1.10"/>
-    </versions>
-
-    <message>
-
-      <para>
-        <literal>MySQL-shared-compat-5.1.9-0.i386.rpm</literal>
-        incorrectly depended on <literal>glibc</literal> 2.3 and could
-        not be installed on a <literal>glibc</literal> 2.2 system.
-      </para>
-
-    </message>
-
-  </logentry>
-
-  <logentry entrytype="bug">
-
-    <tags>
       <manual type="HANDLER"/>
     </tags>
 

@@ -113827,36 +113629,6 @@
 
   </logentry>
 
-  <logentry entrytype="feature">
-
-    <tags>
-      <manual type="sysdate-is-now"/>
-      <manual type="NOW"/>
-      <manual type="mysqld"/>
-      <manual type="SYSDATE"/>
-    </tags>
-
-    <bugs>
-      <fixes bugid="15101"/>
-    </bugs>
-
-    <versions>
-      <version ver="5.0.20"/>
-    </versions>
-
-    <message>
-
-      <para>
-        Added the <option>--sysdate-is-now</option> option to
-        <command>mysqld</command> to enable <literal>SYSDATE()</literal>
-        to be treated as an alias for <literal>NOW()</literal>. See
-        <xref linkend="date-and-time-functions"/>.
-      </para>
-
-    </message>
-
-  </logentry>
-
   <logentry entrytype="bug">
 
     <tags>

@@ -114264,35 +114036,7 @@
 
   <logentry entrytype="bug">
 
-    <tags>
-      <highlight type="cluster"/>
-      <manual type="replication"/>
-      <manual type="cluster"/>
-    </tags>
-
     <bugs>
-      <fixes bugid="15303"/>
-    </bugs>
-
-    <versions>
-      <version ver="5.1.12"/>
-    </versions>
-
-    <message>
-
-      <para>
-        A problem with takeover during a system restart caused ordered
-        indexes to be rebuilt incorrectly. This also adversely affected
-        Cluster Replication.
-      </para>
-
-    </message>
-
-  </logentry>
-
-  <logentry entrytype="bug">
-
-    <bugs>
       <fixes bugid="5831"/>
     </bugs>
 

@@ -114354,6 +114098,22 @@
       <version ver="4.1.21"/>
     </versions>
 
+    <message ver="4.1.21">
+
+      <para>
+        The omission of leading zeros in dates could lead to erroneous
+        results when these were compared with the output of certain date
+        and time functions.
+      </para>
+
+      <note>
+        <para>
+          The patch for this bug was reverted in MySQL 4.1.22.
+        </para>
+      </note>
+
+    </message>
+
     <message>
 
       <para>

@@ -114857,8 +114617,9 @@
     </bugs>
 
     <versions>
-      <version ver="5.1.12"/>
+      <version ver="4.1.21"/>
       <version ver="5.0.25"/>
+      <version ver="5.1.12"/>
     </versions>
 
     <message>

@@ -116977,27 +116738,6 @@
 
   </logentry>
 
-  <logentry entrytype="feature">
-
-    <bugs>
-      <fixes bugid="15408"/>
-    </bugs>
-
-    <versions>
-      <version ver="5.1.8"/>
-    </versions>
-
-    <message>
-
-      <para>
-        Names of subpartitions must now be unique for an entire table,
-        and not merely within the same partition.
-      </para>
-
-    </message>
-
-  </logentry>
-
   <logentry entrytype="bug">
 
     <tags>

@@ -119769,35 +119509,6 @@
   <logentry entrytype="bug">
 
     <tags>
-      <manual type="Intersection"/>
-      <manual type="index_merge"/>
-    </tags>
-
-    <bugs>
-      <fixes bugid="16201"/>
-    </bugs>
-
-    <versions>
-      <version ver="5.0.25"/>
-    </versions>
-
-    <message>
-
-      <para>
-        The
-        <literal>index_merge</literal>/<literal>Intersection</literal>
-        optimizer could have a memory overrrun when the number of table
-        columns covered by an index is sufficiently large, possibly
-        resulting in a server crash.
-      </para>
-
-    </message>
-
-  </logentry>
-
-  <logentry entrytype="bug">
-
-    <tags>
       <manual type="AND"/>
       <manual type="subqueries"/>
     </tags>

@@ -121944,33 +121655,7 @@
 
   <logentry entrytype="bug">
 
-    <tags>
-      <manual type="Windows"/>
-      <manual type="mysql_close()"/>
-    </tags>
-
     <bugs>
-      <fixes bugid="15846"/>
-    </bugs>
-
-    <versions>
-      <version ver="4.1.19"/>
-    </versions>
-
-    <message>
-
-      <para>
-        The <function role="capi">mysql_close()</function> C API
-        function leaked handles for share-memory connections on Windows.
-      </para>
-
-    </message>
-
-  </logentry>
-
-  <logentry entrytype="bug">
-
-    <bugs>
       <fixes bugid="7209"/>
     </bugs>
 

@@ -122461,33 +122146,6 @@
 
   </logentry>
 
-  <logentry entrytype="feature">
-
-    <tags>
-      <manual type="replication"/>
-      <manual type="binary log"/>
-    </tags>
-
-    <bugs>
-      <fixes bugid="17857"/>
-      <fixes bugid="16421"/>
-    </bugs>
-
-    <versions>
-      <version ver="5.1.18"/>
-    </versions>
-
-    <message>
-
-      <para>
-        The effects of scheduled events were not replicated (that is,
-        binary logging of scheduled events did not work).
-      </para>
-
-    </message>
-
-  </logentry>
-
   <logentry entrytype="bug">
 
     <tags>

@@ -124639,32 +124297,7 @@
 
   <logentry entrytype="bug">
 
-    <tags>
-      <manual type="triggers"/>
-    </tags>
-
     <bugs>
-      <fixes bugid="15921"/>
-    </bugs>
-
-    <versions>
-      <version ver="5.1.9"/>
-    </versions>
-
-    <message>
-
-      <para>
-        Triggers created in one version of the server could not be
-        dropped after upgrading to a newer version.
-      </para>
-
-    </message>
-
-  </logentry>
-
-  <logentry entrytype="bug">
-
-    <bugs>
       <introducedby bugid="29354"/>
     </bugs>
 

@@ -129754,33 +129387,7 @@
 
   <logentry entrytype="bug">
 
-    <tags>
-      <manual type="zlib"/>
-    </tags>
-
     <bugs>
-      <fixes bugid="15223"/>
-    </bugs>
-
-    <versions>
-      <version ver="5.0.17"/>
-      <version ver="4.1.18"/>
-    </versions>
-
-    <message>
-
-      <para>
-        RPM packages had an incorrect <literal>zlib</literal>
-        dependency.
-      </para>
-
-    </message>
-
-  </logentry>
-
-  <logentry entrytype="bug">
-
-    <bugs>
       <fixes bugid="21432"/>
     </bugs>
 

@@ -133780,12 +133387,26 @@
     </bugs>
 
     <versions>
+      <version ver="4.1.19"/>
       <version ver="5.0.21"/>
+      <version ver="5.1.10"/>
     </versions>
 
-    <message>
+    <message ver="4.1.19">
 
       <para>
+        <literal>MySQL-shared-compat-4.1.15-0.i386.rpm</literal>,
+        <literal>MySQL-shared-compat-4.1.16-0.i386.rpm</literal>, and
+        <literal>MySQL-shared-compat-4.1.18-0.i386.rpm</literal>
+        incorrectly depended on <literal>glibc</literal> 2.3 and could
+        not be installed on a <literal>glibc</literal> 2.2 system.
+      </para>
+
+    </message>
+
+    <message ver="5.0.21">
+
+      <para>
         <literal>MySQL-shared-compat-5.0.13-0.i386.rpm</literal>,
         <literal>MySQL-shared-compat-5.0.15-0.i386.rpm</literal>,
         <literal>MySQL-shared-compat-5.0.18-0.i386.rpm</literal>,

@@ -133798,6 +133419,16 @@
 
     </message>
 
+    <message ver="5.1.10">
+
+      <para>
+        <literal>MySQL-shared-compat-5.1.9-0.i386.rpm</literal>
+        incorrectly depended on <literal>glibc</literal> 2.3 and could
+        not be installed on a <literal>glibc</literal> 2.2 system.
+      </para>
+
+    </message>
+
   </logentry>
 
   <logentry entrytype="bug">

@@ -133986,37 +133617,6 @@
   <logentry entrytype="bug">
 
     <tags>
-      <manual type="innodb_locks_unsafe_for_binlog"/>
-      <manual type="LEFT JOIN"/>
-      <manual type="DELETE"/>
-      <manual type="IS NULL"/>
-    </tags>
-
-    <bugs>
-      <fixes bugid="15650"/>
-    </bugs>
-
-    <versions>
-      <version ver="5.0.19"/>
-    </versions>
-
-    <message>
-
-      <para>
-        A <literal>DELETE</literal> statement involving a <literal>LEFT
-        JOIN</literal> and an <literal>IS NULL</literal> test on the
-        right-hand table of the join crashed the server when the
-        <literal>innodb_locks_unsafe_for_binlog</literal> option was
-        enabled.
-      </para>
-
-    </message>
-
-  </logentry>
-
-  <logentry entrytype="bug">
-
-    <tags>
       <manual type="stored routine"/>
     </tags>
 

@@ -136685,6 +136285,7 @@
 
     <versions>
       <version ver="5.0.21"/>
+      <version ver="5.1.12"/>
     </versions>
 
     <message>


Thread
svn commit - mysqldoc@docsrva: r8554 - trunk/dynamic-docs/changelogjon6 Nov