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 … FROM S WHERE
…</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 … FROM S WHERE
…</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 … FROM S WHERE
…</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.1 | paul | 13 Jan |
