Author: jstephens
Date: 2007-09-14 17:24:45 +0200 (Fri, 14 Sep 2007)
New Revision: 7861
Log:
Documented Server bugfixes:
Bug #29408, Bug #29938, Bug #30385, Bug #30244, Bug #30245
Modified:
trunk/refman-4.1/functions-core.xml
trunk/refman-4.1/news-4.1.xml
trunk/refman-4.1/replication.xml
trunk/refman-5.0/functions-core.xml
trunk/refman-5.0/releasenotes-es-5.0.xml
trunk/refman-5.0/replication-notes.xml
trunk/refman-5.1/functions-core.xml
trunk/refman-5.1/news-5.1.xml
trunk/refman-5.1/replication-notes.xml
Modified: trunk/refman-4.1/functions-core.xml
===================================================================
--- trunk/refman-4.1/functions-core.xml 2007-09-14 12:49:15 UTC (rev 7860)
+++ trunk/refman-4.1/functions-core.xml 2007-09-14 15:24:45 UTC (rev 7861)
Changed blocks: 1, Lines Added: 8, Lines Deleted: 0; 689 bytes
@@ -14446,6 +14446,14 @@
<literal>FOUND_ROWS()</literal> are available starting at
MySQL 4.0.0.
</para>
+
+ <important>
+ <para>
+ <literal>FOUND_ROWS()</literal> is not replicated
+ reliably, and should not be used with databases that are
+ to be replicated.
+ </para>
+ </important>
</listitem>
<listitem>
Modified: trunk/refman-4.1/news-4.1.xml
===================================================================
--- trunk/refman-4.1/news-4.1.xml 2007-09-14 12:49:15 UTC (rev 7860)
+++ trunk/refman-4.1/news-4.1.xml 2007-09-14 15:24:45 UTC (rev 7861)
Changed blocks: 1, Lines Added: 9, Lines Deleted: 0; 813 bytes
@@ -201,6 +201,15 @@
<listitem>
<para>
+ Issuing a <literal>DELETE</literal> statement having both an
+ <literal>ORDER BY</literal> clause and a
+ <literal>LIMIT</literal> clause could cause
+ <command>mysqld</command> to crash. (Bug #30385)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
If one thread was performing concurrent inserts, other threads
reading from the same table using equality key searches could
see the index values for new rows before the data values had
Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml 2007-09-14 12:49:15 UTC (rev 7860)
+++ trunk/refman-4.1/replication.xml 2007-09-14 15:24:45 UTC (rev 7861)
Changed blocks: 1, Lines Added: 5, Lines Deleted: 0; 558 bytes
@@ -1494,6 +1494,11 @@
a statement such as <literal>INSERT INTO mytable
VALUES(GET_LOCK(...))</literal>.)
</para>
+
+ <para>
+ The <literal>FOUND_ROWS()</literal> function is also not
+ replicated reliably.
+ </para>
</listitem>
<listitem>
Modified: trunk/refman-5.0/functions-core.xml
===================================================================
--- trunk/refman-5.0/functions-core.xml 2007-09-14 12:49:15 UTC (rev 7860)
+++ trunk/refman-5.0/functions-core.xml 2007-09-14 15:24:45 UTC (rev 7861)
Changed blocks: 2, Lines Added: 14, Lines Deleted: 0; 953 bytes
@@ -14517,6 +14517,14 @@
</listitem>
</itemizedlist>
+
+ <important>
+ <para>
+ <literal>FOUND_ROWS()</literal> is not replicated
+ reliably, and should not be used with databases that are
+ to be replicated.
+ </para>
+ </important>
</listitem>
<listitem>
@@ -14857,6 +14865,12 @@
<para>
<literal>ROW_COUNT()</literal> was added in MySQL 5.0.1.
</para>
+
+ <important>
+ <para>
+ <literal>ROW_COUNT()</literal> is not replicated reliably.
+ </para>
+ </important>
</listitem>
<listitem>
Modified: trunk/refman-5.0/releasenotes-es-5.0.xml
===================================================================
--- trunk/refman-5.0/releasenotes-es-5.0.xml 2007-09-14 12:49:15 UTC (rev 7860)
+++ trunk/refman-5.0/releasenotes-es-5.0.xml 2007-09-14 15:24:45 UTC (rev 7861)
Changed blocks: 1, Lines Added: 28, Lines Deleted: 0; 1466 bytes
@@ -83,6 +83,34 @@
<listitem>
<para>
+ Using <literal>DISTINCT</literal> or <literal>GROUP
+ BY</literal> on a <literal>BIT</literal> column in a
+ <literal>SELECT</literal> statement caused the column to be
+ cast internally as an integer, with incorrect results being
+ returned from the query. (Bug #30245)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Issuing a <literal>DELETE</literal> statement having both an
+ <literal>ORDER BY</literal> clause and a
+ <literal>LIMIT</literal> clause could cause
+ <command>mysqld</command> to crash. (Bug #30385)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If a view used a function in its <literal>SELECT</literal>
+ statement, the columns from the view were not inserted into
+ the <literal>INFORMATION_SCHEMA.COLUMNS</literal> table. (Bug
+ #29408)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<command>mysql_upgrade</command> could run binaries
dynamically linked against incorrect versions of shared
libraries. (Bug #28560)
Modified: trunk/refman-5.0/replication-notes.xml
===================================================================
--- trunk/refman-5.0/replication-notes.xml 2007-09-14 12:49:15 UTC (rev 7860)
+++ trunk/refman-5.0/replication-notes.xml 2007-09-14 15:24:45 UTC (rev 7861)
Changed blocks: 2, Lines Added: 7, Lines Deleted: 1; 851 bytes
@@ -77,7 +77,7 @@
<section id="replication-features-autoincid">
- <title>Replication an <literal>AUTO_INCREMENT</literal></title>
+ <title>Replication and <literal>AUTO_INCREMENT</literal></title>
<para>
Replication of <literal>AUTO_INCREMENT</literal>,
@@ -464,6 +464,12 @@
results on master and slave.
</para>
+ <para>
+ The <literal>FOUND_ROWS()</literal> and
+ <literal>ROW_COUNT()</literal> functions are also not replicated
+ reliably.
+ </para>
+
</section>
<section id="replication-features-load">
Modified: trunk/refman-5.1/functions-core.xml
===================================================================
--- trunk/refman-5.1/functions-core.xml 2007-09-14 12:49:15 UTC (rev 7860)
+++ trunk/refman-5.1/functions-core.xml 2007-09-14 15:24:45 UTC (rev 7861)
Changed blocks: 2, Lines Added: 18, Lines Deleted: 0; 1178 bytes
@@ -15216,6 +15216,15 @@
</listitem>
</itemizedlist>
+
+ <important>
+ <para>
+ <literal>FOUND_ROWS()</literal> is not replicated reliably
+ using statement-based replication. Starting with MySQL
+ 5.1.23, this function is automatically replicated using
+ row-based replication.
+ </para>
+ </important>
</listitem>
<listitem>
@@ -15575,6 +15584,15 @@
+-------------+
1 row in set (0.00 sec)
</programlisting>
+
+ <important>
+ <para>
+ <literal>ROW_COUNT()</literal> is not replicated reliably
+ using statement-based replication. Beginning with MySQL
+ 5.1.23, this function is automatically replicated using
+ row-based replication. (Bug #30244)
+ </para>
+ </important>
</listitem>
<listitem>
Modified: trunk/refman-5.1/news-5.1.xml
===================================================================
--- trunk/refman-5.1/news-5.1.xml 2007-09-14 12:49:15 UTC (rev 7860)
+++ trunk/refman-5.1/news-5.1.xml 2007-09-14 15:24:45 UTC (rev 7861)
Changed blocks: 2, Lines Added: 49, Lines Deleted: 2; 2572 bytes
@@ -76,6 +76,16 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ The <literal>FOUND_ROWS()</literal> and
+ <literal>ROW_COUNT()</literal> functions do not replicate
+ correctly using statement-based replication. These functions
+ are now automatically replicated using row-baded replication.
+ (Bug #30244)
+ </para>
+ </listitem>
+
</itemizedlist>
<para>
@@ -90,13 +100,50 @@
<listitem>
<para>
+ Using <literal>DISTINCT</literal> or <literal>GROUP
+ BY</literal> on a <literal>BIT</literal> column in a
+ <literal>SELECT</literal> statement caused the column to be
+ cast internally as an integer, with incorrect results being
+ returned from the query. (Bug #30245)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Issuing a <literal>DELETE</literal> statement having both an
+ <literal>ORDER BY</literal> clause and a
+ <literal>LIMIT</literal> clause could cause
+ <command>mysqld</command> to crash. (Bug #30385)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If a view used a function in its <literal>SELECT</literal>
+ statement, the columns from the view were not inserted into
+ the <literal>INFORMATION_SCHEMA.COLUMNS</literal> table. (Bug
+ #29408)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>mysqldump <option>--skip-events
+ --all-databases</option></command> dumped data from the
+ <literal>mysqld.event</literal> table, and when restoring from
+ this dump, events were created in spite of the
+ <option>--skip-events</option> option. (Bug #29938)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
Replicating from a master table to a slave table where the
size of a <literal>CHAR</literal> or
<literal>VARCHAR</literal> column was a different size would
cause <command>mysqld</command> to crash. For more information
on replicating with different column definitions, see
- <xref
- linkend="replication-features-diffcolumns"/>.
+ <xref linkend="replication-features-diffcolumns"/>.
</para>
</listitem>
Modified: trunk/refman-5.1/replication-notes.xml
===================================================================
--- trunk/refman-5.1/replication-notes.xml 2007-09-14 12:49:15 UTC (rev 7860)
+++ trunk/refman-5.1/replication-notes.xml 2007-09-14 15:24:45 UTC (rev 7861)
Changed blocks: 1, Lines Added: 8, Lines Deleted: 0; 742 bytes
@@ -887,6 +887,14 @@
INSERT INTO t2 SELECT UUID(), * FROM t1;
</programlisting>
+ <para>
+ The <literal>FOUND_ROWS()</literal> and
+ <literal>ROW_COUNT()</literal> functions are not replicated
+ reliably using statement-based replication. Beginning with MySQL
+ 5.1.23, this function is automatically replicated using
+ row-based replication. (Bug #30244)
+ </para>
+
</section>
<section id="replication-features-mastercrash">
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r7861 - in trunk: refman-4.1 refman-5.0 refman-5.1 | jon | 14 Sep |
