svn commit - mysqldoc@docsrva: r17445 - in trunk: dynamic-docs/changelog refman-5.1

[jon.stephens]

Author: jstephens
Date: 2009-11-04 18:57:50 +0100 (Wed, 04 Nov 2009)
New Revision: 17445

Log:

Documented Replication bugfixes:

	Bug #34582, Bug #48297

Noted workaround for LOAD DATA/current DB issue in 5.1.40



Modified:
   trunk/dynamic-docs/changelog/mysqld-1.xml
   trunk/refman-5.1/sql-syntax-data-manipulation.xml


Modified: trunk/dynamic-docs/changelog/mysqld-1.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-1.xml	2009-11-04 17:41:15 UTC (rev 17444)
+++ trunk/dynamic-docs/changelog/mysqld-1.xml	2009-11-04 17:57:50 UTC (rev 17445)
Changed blocks: 1, Lines Added: 65, Lines Deleted: 0; 2060 bytes

@@ -9,6 +9,71 @@
   <logentry entrytype="bug">
 
     <tags>
+      <highlight type="replication"/>
+      <manual type="FLUSH LOGS"/>
+    </tags>
+
+    <bugs>
+      <fixes bugid="34582"/>
+    </bugs>
+
+    <versions>
+      <version ver="5.1.41"/>
+    </versions>
+
+    <message>
+
+      <para>
+        <literal role="stmt" condition="flush">FLUSH LOGS</literal> did
+        not actually close and reopen the binary log index file.
+      </para>
+
+    </message>
+
+  </logentry>
+
+  <logentry entrytype="bug">
+
+    <tags>
+      <highlight type="replication"/>
+      <manual type="LOAD DATA"/>
+    </tags>
+
+    <bugs>
+      <fixes bugid="48297"/>
+    </bugs>
+
+    <versions>
+      <version ver="5.1.41"/>
+    </versions>
+
+    <message>
+
+      <para>
+        When using statement-based or mixed-format replication, the
+        database name was not written to the binary log when executing a
+        <literal role="stmt">LOAD DATA</literal> statement. This caused
+        problems when the table being loaded belonged to a database
+        other than the current database; data could be loaded into the
+        wrong table (if a table having the same name existed in the
+        current database) or replication could fail (if no table having
+        that name existed in the current database). Now a table
+        referenced in a <literal role="stmt">LOAD DATA</literal>
+        statement is always logged using its fully qualified name when
+        the database to which it belongs is not the current database.
+      </para>
+
+      <para>
+        This issue occurred in MySQL 5.1.40 only.
+      </para>
+
+    </message>
+
+  </logentry>
+
+  <logentry entrytype="bug">
+
+    <tags>
       <highlight type="diskdata"/>
       <manual type="error reporting"/>
       <manual type="InitialLogFileGroup"/>


Modified: trunk/refman-5.1/sql-syntax-data-manipulation.xml
===================================================================
--- trunk/refman-5.1/sql-syntax-data-manipulation.xml	2009-11-04 17:41:15 UTC (rev 17444)
+++ trunk/refman-5.1/sql-syntax-data-manipulation.xml	2009-11-04 17:57:50 UTC (rev 17445)
Changed blocks: 1, Lines Added: 21, Lines Deleted: 0; 1480 bytes

@@ -2429,6 +2429,27 @@
       backslashes. If you do use backslashes, you must double them.
     </para>
 
+    <note>
+      <para>
+        A regression in MySQL 5.1.40 caused the database referenced in a
+        fully qualified table name to be ignored by
+        <literal role="stmt">LOAD DATA</literal> when using replication
+        with either <literal>STATEMENT</literal> or
+        <literal>MIXED</literal> as the binary logging format; this
+        could lead to problems if the table was not in the current
+        database. As a workaround, you can specify the correct database
+        with the <literal role="stmt">USE</literal> statement prior to
+        executing <literal role="stmt">LOAD DATA</literal>. If
+        necessary, you can reset the current database with a second
+        <literal role="stmt">USE</literal> statement following the
+        <literal role="stmt">LOAD DATA</literal> statement.
+      </para>
+
+      <para>
+        This issue was fixed in MySQL 5.1.41. (Bug #48297)
+      </para>
+    </note>
+
     <para>
       For security reasons, when reading text files located on the
       server, the files must either reside in the database directory or