List:Commits« Previous MessageNext Message »
From:paul Date:January 13 2006 4:00am
Subject:svn commit - mysqldoc@docsrva: r797 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-13 05:00:46 +0100 (Fri, 13 Jan 2006)
New Revision: 797

Log:
 r6153@frost:  paul | 2006-01-12 22:00:28 -0600
 Update description of INSERT ... SELECT locking for InnoDB (5.0 and up).


Modified:
   trunk/
   trunk/refman-4.1/innodb.xml
   trunk/refman-5.0/innodb.xml
   trunk/refman-5.1/innodb.xml


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6149
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2101
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6153
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2101

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2006-01-13 03:50:48 UTC (rev 796)
+++ trunk/refman-4.1/innodb.xml	2006-01-13 04:00:46 UTC (rev 797)
@@ -4320,6 +4320,11 @@
         </listitem>
 
         <listitem>
+          <remark role="note">
+            This behavior changes in 5.0. Don't merge the 5.0
+            description in here.
+          </remark>
+
           <para>
             <literal>INSERT INTO T SELECT &hellip; FROM S WHERE
             &hellip;</literal> sets an exclusive (non-next-key) lock on

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-13 03:50:48 UTC (rev 796)
+++ trunk/refman-5.0/innodb.xml	2006-01-13 04:00:46 UTC (rev 797)
@@ -4274,13 +4274,16 @@
           <para>
             <literal>INSERT INTO T SELECT &hellip; FROM S WHERE
             &hellip;</literal> sets an exclusive (non-next-key) lock on
-            each row inserted into <literal>T</literal>. It does the
-            search on <literal>S</literal> as a consistent read, but
-            sets shared next-key locks on <literal>S</literal> if MySQL
-            binary logging is turned on. <literal>InnoDB</literal> has
-            to set locks in the latter case: In roll-forward recovery
-            from a backup, every SQL statement has to be executed in
-            exactly the same way it was done originally.
+            each row inserted into <literal>T</literal>.
+            <literal>InnoDB</literal> sets shared next-key locks locks
+            on <literal>S</literal>, unless
+            <literal>innodb_locks_unsafe_for_binlog</literal> is
+            enabled, in which case it does the search on
+            <literal>S</literal> as a consistent read.
+            <literal>InnoDB</literal> has to set locks in the latter
+            case: In roll-forward recovery from a backup, every SQL
+            statement has to be executed in exactly the same way it was
+            done originally.
           </para>
         </listitem>
 

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-13 03:50:48 UTC (rev 796)
+++ trunk/refman-5.1/innodb.xml	2006-01-13 04:00:46 UTC (rev 797)
@@ -4249,13 +4249,16 @@
           <para>
             <literal>INSERT INTO T SELECT &hellip; FROM S WHERE
             &hellip;</literal> sets an exclusive (non-next-key) lock on
-            each row inserted into <literal>T</literal>. It does the
-            search on <literal>S</literal> as a consistent read, but
-            sets shared next-key locks on <literal>S</literal> if MySQL
-            binary logging is turned on. <literal>InnoDB</literal> has
-            to set locks in the latter case: In roll-forward recovery
-            from a backup, every SQL statement has to be executed in
-            exactly the same way it was done originally.
+            each row inserted into <literal>T</literal>.
+            <literal>InnoDB</literal> sets shared next-key locks locks
+            on <literal>S</literal>, unless
+            <literal>innodb_locks_unsafe_for_binlog</literal> is
+            enabled, in which case it does the search on
+            <literal>S</literal> as a consistent read.
+            <literal>InnoDB</literal> has to set locks in the latter
+            case: In roll-forward recovery from a backup, every SQL
+            statement has to be executed in exactly the same way it was
+            done originally.
           </para>
         </listitem>
 

Thread
svn commit - mysqldoc@docsrva: r797 - in trunk: . refman-4.1 refman-5.0 refman-5.1paul13 Jan