svn commit - mysqldoc@docsrva: r11840 - in trunk: dynamic-docs/changelog refman-5.0 refman-5.1 refman-6.0

[jon]

Author: jstephens
Date: 2008-09-16 21:00:01 +0200 (Tue, 16 Sep 2008)
New Revision: 11840

Log:

Updated changelog entry for Bug #23333; also added relevant info to
binary-log (Thanks, Todd!)



Modified:
   trunk/dynamic-docs/changelog/mysqld.xml
   trunk/refman-5.0/dba-core.xml
   trunk/refman-5.1/dba-core.xml
   trunk/refman-6.0/dba-core.xml


Modified: trunk/dynamic-docs/changelog/mysqld.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld.xml	2008-09-16 16:58:14 UTC (rev 11839)
+++ trunk/dynamic-docs/changelog/mysqld.xml	2008-09-16 19:00:01 UTC (rev 11840)
Changed blocks: 1, Lines Added: 10, Lines Deleted: 0; 884 bytes

@@ -167,6 +167,16 @@
         the master have a row that the copy on the slave did not.
       </para>
 
+      <para>
+        In addition, when an <literal>INSERT ... ON DUPLICATE KEY
+        UPDATE</literal> statement encountered a duplicate key
+        constraint, but the <literal>UPDATE</literal> did not actually
+        change any data, the statement was not logged. As a result of
+        this fix, such statements are now treated the same for logging
+        purposes as other <literal>UPDATE</literal> statements, and so
+        are written to the binary log.
+      </para>
+
     </message>
 
   </logentry>


Modified: trunk/refman-5.0/dba-core.xml
===================================================================
--- trunk/refman-5.0/dba-core.xml	2008-09-16 16:58:14 UTC (rev 11839)
+++ trunk/refman-5.0/dba-core.xml	2008-09-16 19:00:01 UTC (rev 11840)
Changed blocks: 1, Lines Added: 19, Lines Deleted: 8; 2151 bytes

@@ -12607,14 +12607,25 @@
 
       <para>
         Updates to non-transactional tables are stored in the binary log
-        immediately after execution. Within an uncommitted transaction,
-        all updates (<literal>UPDATE</literal>,
-        <literal>DELETE</literal>, or <literal>INSERT</literal>)
that
-        change transactional tables such as <literal>BDB</literal> or
-        <literal>InnoDB</literal> tables are cached until a
-        <literal>COMMIT</literal> statement is received by the server.
-        At that point, <command>mysqld</command> writes the entire
-        transaction to the binary log before the
+        immediately after execution. In MySQL 5.0.53 and earlier
+        versions of MySQL &current-series;, an <literal>UPDATE</literal>
+        statement using a stored function that modified a
+        non-transactional table was not logged if it failed, and an
+        <literal>INSERT ... ON DUPLICATE KEY UPDATE</literal> statement
+        that encountered a duplicate key constraint &mdash; but which
+        did not actually change any data &mdash; was not logged.
+        Beginning with MySQL 5.0.54, both of these statements are
+        written to the binary log. (Bug #23333)
+      </para>
+
+      <para>
+        Within an uncommitted transaction, all updates
+        (<literal>UPDATE</literal>, <literal>DELETE</literal>, or
+        <literal>INSERT</literal>) that change transactional tables such
+        as <literal>BDB</literal> or <literal>InnoDB</literal>
tables
+        are cached until a <literal>COMMIT</literal> statement is
+        received by the server. At that point, <command>mysqld</command>
+        writes the entire transaction to the binary log before the
         <literal>COMMIT</literal> is executed. When the thread that
         handles the transaction starts, it allocates a buffer of
         <literal>binlog_cache_size</literal> to buffer statements. If a


Modified: trunk/refman-5.1/dba-core.xml
===================================================================
--- trunk/refman-5.1/dba-core.xml	2008-09-16 16:58:14 UTC (rev 11839)
+++ trunk/refman-5.1/dba-core.xml	2008-09-16 19:00:01 UTC (rev 11840)
Changed blocks: 1, Lines Added: 17, Lines Deleted: 5; 1840 bytes

@@ -13668,11 +13668,23 @@
 
       <para>
         Updates to non-transactional tables are stored in the binary log
-        immediately after execution. Within an uncommitted transaction,
-        all updates (<literal>UPDATE</literal>,
-        <literal>DELETE</literal>, or <literal>INSERT</literal>)
that
-        change transactional tables such as <literal>InnoDB</literal>
-        tables are cached until a <literal>COMMIT</literal> statement is
+        immediately after execution. In MySQL 5.1.22 and earlier
+        versions of MySQL &current-series;, an <literal>UPDATE</literal>
+        statement using a stored function that modified a
+        non-transactional table was not logged if it failed, and an
+        <literal>INSERT ... ON DUPLICATE KEY UPDATE</literal> statement
+        that encountered a duplicate key constraint &mdash; but which
+        did not actually change any data &mdash; was not logged.
+        Beginning with MySQL 5.1.23, both of these statements are
+        written to the binary log. (Bug #23333)
+      </para>
+
+      <para>
+        Within an uncommitted transaction, all updates
+        (<literal>UPDATE</literal>, <literal>DELETE</literal>, or
+        <literal>INSERT</literal>) that change transactional tables such
+        as <literal>BDB</literal> or <literal>InnoDB</literal>
tables
+        are cached until a <literal>COMMIT</literal> statement is
         received by the server. At that point, <command>mysqld</command>
         writes the entire transaction to the binary log before the
         <literal>COMMIT</literal> is executed. When the thread that


Modified: trunk/refman-6.0/dba-core.xml
===================================================================
--- trunk/refman-6.0/dba-core.xml	2008-09-16 16:58:14 UTC (rev 11839)
+++ trunk/refman-6.0/dba-core.xml	2008-09-16 19:00:01 UTC (rev 11840)
Changed blocks: 1, Lines Added: 17, Lines Deleted: 5; 1838 bytes

@@ -13607,11 +13607,23 @@
 
       <para>
         Updates to non-transactional tables are stored in the binary log
-        immediately after execution. Within an uncommitted transaction,
-        all updates (<literal>UPDATE</literal>,
-        <literal>DELETE</literal>, or <literal>INSERT</literal>)
that
-        change transactional tables such as <literal>InnoDB</literal>
-        tables are cached until a <literal>COMMIT</literal> statement is
+        immediately after execution. In MySQL 6.0.3 and earlier versions
+        of MySQL &current-series;, an <literal>UPDATE</literal>
+        statement using a stored function that modified a
+        non-transactional table was not logged if it failed, and an
+        <literal>INSERT ... ON DUPLICATE KEY UPDATE</literal> statement
+        that encountered a duplicate key constraint &mdash; but which
+        did not actually change any data &mdash; was not logged.
+        Beginning with MySQL 6.0.4, both of these statements are written
+        to the binary log. (Bug #23333)
+      </para>
+
+      <para>
+        Within an uncommitted transaction, all updates
+        (<literal>UPDATE</literal>, <literal>DELETE</literal>, or
+        <literal>INSERT</literal>) that change transactional tables such
+        as <literal>BDB</literal> or <literal>InnoDB</literal>
tables
+        are cached until a <literal>COMMIT</literal> statement is
         received by the server. At that point, <command>mysqld</command>
         writes the entire transaction to the binary log before the
         <literal>COMMIT</literal> is executed. When the thread that