bk commit - mysqldoc@docsrva tree (Mike.Hillyer:1.3555)

[mhillyer]

Below is the list of changes that have just been committed into a local
mysqldoc repository of root. When root does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html

ChangeSet
  1.3555 05/09/13 23:06:44 Mike.Hillyer@stripped +2 -0
  Document bigfixes: 12611,13054,12550,12695

  refman-common/news-5.0.xml
    1.181 05/09/13 23:06:43 Mike.Hillyer@stripped +35 -4
    Document Bugfixes

  refman-common/news-4.1.xml
    1.94 05/09/13 23:06:43 Mike.Hillyer@stripped +30 -7
    Document Bugfixes

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	Mike.Hillyer
# Host:	www.openwin.org
# Root:	/home/mysqldoc/mysqldoc

--- 1.93/refman-common/news-4.1.xml	2005-09-13 19:02:47 -06:00
+++ 1.94/refman-common/news-4.1.xml	2005-09-13 23:06:43 -06:00
@@ -202,6 +202,30 @@
 
       <listitem>
         <para>
+          Performing an <literal>IS NULL</literal> or
+          <literal>ISNULL()</literal> check on the
+          <literal>MIN()</literal> or <literal>MAX()</literal> of
an
+          indexed columns produced incorrect results. (Bug #12695)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          The NDB <literal>START BACKUP</literal> command could be
+          interrupted by a <literal>SHOW</literal> command. (Bug #13054)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          The <literal>LIKE ... ESCAPE</literal> syntax produced invalid
+          results when escape character was larger than one byte. (Bug
+          #12611)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           A client connection thread cleanup problem caused the server
           to crash when closing the connection if the binary log was
           enabled. (Bug #12517)
@@ -2174,11 +2198,10 @@
           and isolation level of the transaction is not set to
           serializable then <literal>InnoDB</literal> uses a consistent
           read for select in clauses like <literal>INSERT
-          INTO…SELECT</literal> and
-          <literal>UPDATE…(SELECT)</literal> that do not specify
-          <literal>FOR UPDATE</literal> or <literal>IN SHARE
-          MODE</literal>. Thus no locks are set to rows read from
-          selected table.
+          INTO…SELECT</literal> and
<literal>UPDATE…(SELECT)</literal>
+          that do not specify <literal>FOR UPDATE</literal> or
+          <literal>IN SHARE MODE</literal>. Thus no locks are set to
+          rows read from selected table.
         </para>
       </listitem>
 
@@ -3968,8 +3991,8 @@
       <listitem>
         <para>
           InnoDB: Relaxed locking in <literal>INSERT…SELECT</literal>,
-          single table <literal>UPDATE…SELECT</literal> and single
-          table <literal>DELETE…SELECT</literal> clauses when
+          single table <literal>UPDATE…SELECT</literal> and single
table
+          <literal>DELETE…SELECT</literal> clauses when
           <literal>innodb_locks_unsafe_for_binlog</literal> is used and
           isolation level of the transaction is not serializable.
           <literal>InnoDB</literal> uses consistent read in these cases

--- 1.180/refman-common/news-5.0.xml	2005-09-13 19:02:44 -06:00
+++ 1.181/refman-common/news-5.0.xml	2005-09-13 23:06:43 -06:00
@@ -243,6 +243,37 @@
 
       <listitem>
         <para>
+          Performing an <literal>IS NULL</literal> check on the
+          <literal>MIN()</literal> or <literal>MAX()</literal> of
an
+          indexed columns produced incorrect results. (Bug #12695)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          The <filename>mysql.server</filename> script contained
+          incorrect path for the <literal>libexec</literal> directory.
+          (Bug #12550)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          The NDB <literal>START BACKUP</literal> command could be
+          interrupted by a <literal>SHOW</literal> command. (Bug #13054)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          The <literal>LIKE ... ESCAPE</literal> syntax produced invalid
+          results when escape character was larger than one byte. (Bug
+          #12611)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           A client connection thread cleanup problem caused the server
           to crash when closing the connection if the binary log was
           enabled. (Bug #12517)
@@ -5473,8 +5504,8 @@
           InnoDB: True <literal>VARCHAR</literal>: InnoDB stored the
           'position' of a row wrong in a column prefix primary key
           index; this could cause MySQL to complain <literal>ERROR 1032:
-          Can't find record …</literal> in an update of the primary
-          key, and also some <literal>ORDER BY</literal> or
+          Can't find record …</literal> in an update of the primary key,
+          and also some <literal>ORDER BY</literal> or
           <literal>DISTINCT</literal> queries. (Bug #9314)
         </para>
       </listitem>
@@ -6376,8 +6407,8 @@
       <listitem>
         <para>
           InnoDB: Relaxed locking in <literal>INSERT…SELECT</literal>,
-          single table <literal>UPDATE…SELECT</literal> and single
-          table <literal>DELETE…SELECT</literal> clauses when
+          single table <literal>UPDATE…SELECT</literal> and single
table
+          <literal>DELETE…SELECT</literal> clauses when
           <literal>innodb_locks_unsafe_for_binlog</literal> is used and
           isolation level of the transaction is not serializable.
           <literal>InnoDB</literal> uses consistent read in these cases