List:Commits« Previous MessageNext Message »
From:paul.dubois Date:March 12 2009 5:56pm
Subject:svn commit - mysqldoc@docsrva: r14202 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0
View as plain text  
Author: paul
Date: 2009-03-12 18:56:00 +0100 (Thu, 12 Mar 2009)
New Revision: 14202

Log:
 r39500@frost:  paul | 2009-03-12 12:58:41 -0500
 InnoDB revisions


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

Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:41755
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:39486
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:36872
   + 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:41755
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:39500
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:36872


Modified: trunk/refman-4.1/se-innodb-core.xml
===================================================================
--- trunk/refman-4.1/se-innodb-core.xml	2009-03-12 15:42:35 UTC (rev 14201)
+++ trunk/refman-4.1/se-innodb-core.xml	2009-03-12 17:56:00 UTC (rev 14202)
Changed blocks: 2, Lines Added: 40, Lines Deleted: 16; 3162 bytes

@@ -1783,22 +1783,8 @@
 
         <para>
           This variable affects how <literal>InnoDB</literal> uses gap
-          locking for searches and index scans. The effect is similar to
-          setting the transaction isolation level to <literal>READ
-          COMMITTED</literal>. Enabling
-          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
-          is a global setting and affects all sessions, whereas the
-          isolation level can be set globally for all sessions, or
-          individually per sesssion. Also,
-          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
-          can be set only at server startup, whereas the isolation level
-          can be set at startup or changed at runtime. For additional
-          details about the effect of isolation level on gap locking,
-          see <xref linkend="set-transaction"/>.
-        </para>
-
-        <para>
-          Normally, <literal>InnoDB</literal> uses an algorithm called
+          locking for searches and index scans. Normally,
+          <literal>InnoDB</literal> uses an algorithm called
           <firstterm>next-key locking</firstterm> that combines
           index-row locking with gap locking. <literal>InnoDB</literal>
           performs row-level locking in such a way that when it searches

@@ -1832,6 +1818,44 @@
         </para>
 
         <para>
+          The effect enabling
+          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
+          is similar to but not identical to setting the transaction
+          isolation level to <literal role="isolevel">READ
+          COMMITTED</literal>:
+        </para>
+
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              Enabling
+              <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
+              is a global setting and affects all sessions, whereas the
+              isolation level can be set globally for all sessions, or
+              individually per sesssion.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
+              can be set only at server startup, whereas the isolation
+              level can be set at startup or changed at runtime.
+            </para>
+          </listitem>
+
+        </itemizedlist>
+
+        <para>
+          <literal role="isolevel">READ COMMITTED</literal> therefore
+          offers finer and more flexible control than
+          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>.
+          For additional details about the effect of isolation level on
+          gap locking, see <xref linkend="set-transaction"/>.
+        </para>
+
+        <para>
           Enabling
           <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
           may cause phantom problems because other sessions can insert


Modified: trunk/refman-5.0/se-innodb-core.xml
===================================================================
--- trunk/refman-5.0/se-innodb-core.xml	2009-03-12 15:42:35 UTC (rev 14201)
+++ trunk/refman-5.0/se-innodb-core.xml	2009-03-12 17:56:00 UTC (rev 14202)
Changed blocks: 4, Lines Added: 43, Lines Deleted: 19; 3952 bytes

@@ -1750,22 +1750,8 @@
 
         <para>
           This variable affects how <literal>InnoDB</literal> uses gap
-          locking for searches and index scans. The effect is similar to
-          setting the transaction isolation level to <literal>READ
-          COMMITTED</literal>. Enabling
-          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
-          is a global setting and affects all sessions, whereas the
-          isolation level can be set globally for all sessions, or
-          individually per sesssion. Also,
-          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
-          can be set only at server startup, whereas the isolation level
-          can be set at startup or changed at runtime. For additional
-          details about the effect of isolation level on gap locking,
-          see <xref linkend="set-transaction"/>.
-        </para>
-
-        <para>
-          Normally, <literal>InnoDB</literal> uses an algorithm called
+          locking for searches and index scans. Normally,
+          <literal>InnoDB</literal> uses an algorithm called
           <firstterm>next-key locking</firstterm> that combines
           index-row locking with gap locking. <literal>InnoDB</literal>
           performs row-level locking in such a way that when it searches

@@ -1799,6 +1785,44 @@
         </para>
 
         <para>
+          The effect enabling
+          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
+          is similar to but not identical to setting the transaction
+          isolation level to <literal role="isolevel">READ
+          COMMITTED</literal>:
+        </para>
+
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              Enabling
+              <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
+              is a global setting and affects all sessions, whereas the
+              isolation level can be set globally for all sessions, or
+              individually per sesssion.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
+              can be set only at server startup, whereas the isolation
+              level can be set at startup or changed at runtime.
+            </para>
+          </listitem>
+
+        </itemizedlist>
+
+        <para>
+          <literal role="isolevel">READ COMMITTED</literal> therefore
+          offers finer and more flexible control than
+          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>.
+          For additional details about the effect of isolation level on
+          gap locking, see <xref linkend="set-transaction"/>.
+        </para>
+
+        <para>
           Enabling
           <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
           may cause phantom problems because other sessions can insert

@@ -1836,7 +1860,7 @@
         <para>
           Starting from MySQL 5.0.2, enabling
           <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
-          has an additional effect: For an
+          has an additional effect. For an
           <literal role="stmt">UPDATE</literal> or a
           <literal role="stmt">DELETE</literal>,
           <literal>InnoDB</literal> holds locks only for rows that it

@@ -1860,8 +1884,8 @@
 
         <para>
           In this case, table has no indexes, so searches and index
-          scans use the hidden clustered index for record locking. See
-          <xref linkend="innodb-index-types"/>.
+          scans use the hidden clustered index for record locking (see
+          <xref linkend="innodb-index-types"/>).
         </para>
 
         <para>


Modified: trunk/refman-5.1/se-innodb-core.xml
===================================================================
--- trunk/refman-5.1/se-innodb-core.xml	2009-03-12 15:42:35 UTC (rev 14201)
+++ trunk/refman-5.1/se-innodb-core.xml	2009-03-12 17:56:00 UTC (rev 14202)
Changed blocks: 4, Lines Added: 43, Lines Deleted: 19; 3921 bytes

@@ -1799,22 +1799,8 @@
 
         <para>
           This variable affects how <literal>InnoDB</literal> uses gap
-          locking for searches and index scans. The effect is similar to
-          setting the transaction isolation level to <literal>READ
-          COMMITTED</literal>. Enabling
-          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
-          is a global setting and affects all sessions, whereas the
-          isolation level can be set globally for all sessions, or
-          individually per sesssion. Also,
-          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
-          can be set only at server startup, whereas the isolation level
-          can be set at startup or changed at runtime. For additional
-          details about the effect of isolation level on gap locking,
-          see <xref linkend="set-transaction"/>.
-        </para>
-
-        <para>
-          Normally, <literal>InnoDB</literal> uses an algorithm called
+          locking for searches and index scans. Normally,
+          <literal>InnoDB</literal> uses an algorithm called
           <firstterm>next-key locking</firstterm> that combines
           index-row locking with gap locking. <literal>InnoDB</literal>
           performs row-level locking in such a way that when it searches

@@ -1848,6 +1834,44 @@
         </para>
 
         <para>
+          The effect enabling
+          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
+          is similar to but not identical to setting the transaction
+          isolation level to <literal role="isolevel">READ
+          COMMITTED</literal>:
+        </para>
+
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              Enabling
+              <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
+              is a global setting and affects all sessions, whereas the
+              isolation level can be set globally for all sessions, or
+              individually per sesssion.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
+              can be set only at server startup, whereas the isolation
+              level can be set at startup or changed at runtime.
+            </para>
+          </listitem>
+
+        </itemizedlist>
+
+        <para>
+          <literal role="isolevel">READ COMMITTED</literal> therefore
+          offers finer and more flexible control than
+          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>.
+          For additional details about the effect of isolation level on
+          gap locking, see <xref linkend="set-transaction"/>.
+        </para>
+
+        <para>
           Enabling
           <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
           may cause phantom problems because other sessions can insert

@@ -1885,7 +1909,7 @@
         <para>
           Enabling
           <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
-          has additional effects: For an
+          has additional effects. For an
           <literal role="stmt">UPDATE</literal> or a
           <literal role="stmt">DELETE</literal>,
           <literal>InnoDB</literal> holds locks only for rows that it

@@ -1913,8 +1937,8 @@
 
         <para>
           In this case, table has no indexes, so searches and index
-          scans use the hidden clustered index for record locking. See
-          <xref linkend="innodb-index-types"/>.
+          scans use the hidden clustered index for record locking (see
+          <xref linkend="innodb-index-types"/>).
         </para>
 
         <para>


Modified: trunk/refman-6.0/se-innodb-core.xml
===================================================================
--- trunk/refman-6.0/se-innodb-core.xml	2009-03-12 15:42:35 UTC (rev 14201)
+++ trunk/refman-6.0/se-innodb-core.xml	2009-03-12 17:56:00 UTC (rev 14202)
Changed blocks: 4, Lines Added: 43, Lines Deleted: 19; 3921 bytes

@@ -1723,22 +1723,8 @@
 
         <para>
           This variable affects how <literal>InnoDB</literal> uses gap
-          locking for searches and index scans. The effect is similar to
-          setting the transaction isolation level to <literal>READ
-          COMMITTED</literal>. Enabling
-          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
-          is a global setting and affects all sessions, whereas the
-          isolation level can be set globally for all sessions, or
-          individually per sesssion. Also,
-          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
-          can be set only at server startup, whereas the isolation level
-          can be set at startup or changed at runtime. For additional
-          details about the effect of isolation level on gap locking,
-          see <xref linkend="set-transaction"/>.
-        </para>
-
-        <para>
-          Normally, <literal>InnoDB</literal> uses an algorithm called
+          locking for searches and index scans. Normally,
+          <literal>InnoDB</literal> uses an algorithm called
           <firstterm>next-key locking</firstterm> that combines
           index-row locking with gap locking. <literal>InnoDB</literal>
           performs row-level locking in such a way that when it searches

@@ -1772,6 +1758,44 @@
         </para>
 
         <para>
+          The effect enabling
+          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
+          is similar to but not identical to setting the transaction
+          isolation level to <literal role="isolevel">READ
+          COMMITTED</literal>:
+        </para>
+
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              Enabling
+              <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
+              is a global setting and affects all sessions, whereas the
+              isolation level can be set globally for all sessions, or
+              individually per sesssion.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
+              can be set only at server startup, whereas the isolation
+              level can be set at startup or changed at runtime.
+            </para>
+          </listitem>
+
+        </itemizedlist>
+
+        <para>
+          <literal role="isolevel">READ COMMITTED</literal> therefore
+          offers finer and more flexible control than
+          <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>.
+          For additional details about the effect of isolation level on
+          gap locking, see <xref linkend="set-transaction"/>.
+        </para>
+
+        <para>
           Enabling
           <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
           may cause phantom problems because other sessions can insert

@@ -1809,7 +1833,7 @@
         <para>
           Enabling
           <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
-          has additional effects: For an
+          has additional effects. For an
           <literal role="stmt">UPDATE</literal> or a
           <literal role="stmt">DELETE</literal>,
           <literal>InnoDB</literal> holds locks only for rows that it

@@ -1837,8 +1861,8 @@
 
         <para>
           In this case, table has no indexes, so searches and index
-          scans use the hidden clustered index for record locking. See
-          <xref linkend="innodb-index-types"/>.
+          scans use the hidden clustered index for record locking (see
+          <xref linkend="innodb-index-types"/>).
         </para>
 
         <para>


Thread
svn commit - mysqldoc@docsrva: r14202 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0paul.dubois12 Mar