List:Commits« Previous MessageNext Message »
From:paul Date:January 10 2006 6:03pm
Subject:svn commit - mysqldoc@docsrva: r757 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-10 19:03:14 +0100 (Tue, 10 Jan 2006)
New Revision: 757

Log:
 r6058@frost:  paul | 2006-01-10 11:55:28 -0600
 General revisions.


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:6057
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6058
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2006-01-10 18:02:56 UTC (rev 756)
+++ trunk/refman-4.1/innodb.xml	2006-01-10 18:03:14 UTC (rev 757)
@@ -1443,10 +1443,11 @@
         </para>
 
         <para>
-          This value should currently be set to 0. Because recovery from
-          a backup is done by MySQL using its own log files, there is no
-          need to archive <literal>InnoDB</literal> log files. The
-          default for this variable is 0.
+          Whether to log <literal>InnoDB</literal> archive files. This
+          variable is unused. Recovery from a backup is done by MySQL
+          using its own log files, so there is no need to archive
+          <literal>InnoDB</literal> log files. The default for this
+          variable is 0.
         </para>
       </listitem>
 
@@ -1491,7 +1492,7 @@
         <para>
           The number of log files in the log group.
           <literal>InnoDB</literal> writes to the files in a circular
-          fashion. The default is 2 (recommended).
+          fashion. The default (and recommended) is 2.
         </para>
       </listitem>
 
@@ -1521,14 +1522,8 @@
           90. The main thread in <literal>InnoDB</literal> tries to
           write pages from the buffer pool so that the percentage of
           dirty (not yet written) pages will not exceed this value.
-          Available starting from 4.0.13 and 4.1.1. If you have the
-          <literal>SUPER</literal> privilege, this percentage can be
-          changed while the server is running:
+          Available starting from 4.0.13 and 4.1.1.
         </para>
-
-<programlisting>
-SET GLOBAL innodb_max_dirty_pages_pct = <replaceable>value</replaceable>;
-</programlisting>
       </listitem>
 
       <listitem>
@@ -1539,11 +1534,11 @@
         <para>
           This variable controls how to delay <literal>INSERT</literal>,
           <literal>UPDATE</literal> and <literal>DELETE</literal>
-          operations when the purge operations (see
-          <xref linkend="innodb-multi-versioning"/>) are lagging. The
-          default value of this variable is 0, meaning that there are no
-          delays. <literal>innodb_max_purge_lag</literal> is available
-          as of MySQL 4.0.22 and 4.1.6.
+          operations when the purge operations are lagging (see
+          <xref linkend="innodb-multi-versioning"/>). The default value
+          of this variable is 0, meaning that there are no delays.
+          <literal>innodb_max_purge_lag</literal> is available as of
+          MySQL 4.0.22 and 4.1.6.
         </para>
 
         <para>
@@ -1556,7 +1551,7 @@
           <literal>innodb_max_purge_lag</literal>, each
           <literal>INSERT</literal>, <literal>UPDATE</literal> and
           <literal>DELETE</literal> operation is delayed by
-          ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)*10)-5
+          ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)&times;10)&minus;5
           milliseconds. The delay is computed in the beginning of a
           purge batch, every ten seconds. The operations are not delayed
           if purge cannot run because of an old consistent read view
@@ -1640,9 +1635,8 @@
           internally to take a table lock. In applications using
           <literal>AUTOCOMMIT=1</literal>, <literal>InnoDB</literal>'s
           internal table locks can cause deadlocks. You can set
-          <literal>innodb_table_locks=0</literal> in
-          <filename>my.cnf</filename> (or <filename>my.ini</filename> on
-          Windows) to remove that problem.
+          <literal>innodb_table_locks=0</literal> in the server option
+          file to remove that problem.
         </para>
       </listitem>
 

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-10 18:02:56 UTC (rev 756)
+++ trunk/refman-5.0/innodb.xml	2006-01-10 18:03:14 UTC (rev 757)
@@ -1453,10 +1453,12 @@
         </para>
 
         <para>
-          This value should currently be set to 0. Because recovery from
-          a backup is done by MySQL using its own log files, there is
-          currently no need to archive <literal>InnoDB</literal> log
-          files. The default for this variable is 0.
+          Whether to log <literal>InnoDB</literal> archive files. This
+          variable is present for historical reasons, but is unused.
+          Recovery from a backup is done by MySQL using its own log
+          files, so there is no need to archive
+          <literal>InnoDB</literal> log files. The default for this
+          variable is 0.
         </para>
       </listitem>
 
@@ -1501,7 +1503,7 @@
         <para>
           The number of log files in the log group.
           <literal>InnoDB</literal> writes to the files in a circular
-          fashion. The default is 2 (recommended).
+          fashion. The default (and recommended) is 2.
         </para>
       </listitem>
 
@@ -1530,14 +1532,8 @@
           This is an integer in the range from 0 to 100. The default is
           90. The main thread in <literal>InnoDB</literal> tries to
           write pages from the buffer pool so that the percentage of
-          dirty (not yet written) pages will not exceed this value. If
-          you have the <literal>SUPER</literal> privilege, this
-          percentage can be changed while the server is running:
+          dirty (not yet written) pages will not exceed this value.
         </para>
-
-<programlisting>
-SET GLOBAL innodb_max_dirty_pages_pct = <replaceable>value</replaceable>;
-</programlisting>
       </listitem>
 
       <listitem>
@@ -1548,10 +1544,9 @@
         <para>
           This variable controls how to delay <literal>INSERT</literal>,
           <literal>UPDATE</literal> and <literal>DELETE</literal>
-          operations when the purge operations (see
-          <xref linkend="innodb-multi-versioning"/>) are lagging. The
-          default value of this variable is 0, meaning that there are no
-          delays.
+          operations when the purge operations are lagging (see
+          <xref linkend="innodb-multi-versioning"/>). The default value
+          of this variable is 0, meaning that there are no delays.
         </para>
 
         <para>
@@ -1564,7 +1559,7 @@
           <literal>innodb_max_purge_lag</literal>, each
           <literal>INSERT</literal>, <literal>UPDATE</literal> and
           <literal>DELETE</literal> operation is delayed by
-          ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)*10)-5
+          ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)&times;10)&minus;5
           milliseconds. The delay is computed in the beginning of a
           purge batch, every ten seconds. The operations are not delayed
           if purge cannot run because of an old consistent read view
@@ -1671,8 +1666,7 @@
           applications using <literal>AUTOCOMMIT=1</literal>,
           <literal>InnoDB</literal>'s internal table locks can cause
           deadlocks. You can set <literal>innodb_table_locks=0</literal>
-          in <filename>my.cnf</filename> (or <filename>my.ini</filename>
-          on Windows) to remove that problem.
+          in the server option file to remove that problem.
         </para>
       </listitem>
 
@@ -1700,20 +1694,18 @@
         </para>
       </listitem>
 
-<!--   
       <listitem>
-        <remark role="todo">
-          document innodb_thread_sleep_delay
-        </remark>
-
         <para>
           <literal>innodb_thread_sleep_delay</literal>
         </para>
 
         <para>
+          How long <literal>InnoDB</literal> threads sleep before
+          joining the <literal>InnoDB</literal> queue, in microseconds.
+          The default value is 10,000. A value of 0 disables sleep. This
+          variable was added in MySQL 5.0.3.
         </para>
       </listitem>
--->
 
       <listitem>
         <para>

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-10 18:02:56 UTC (rev 756)
+++ trunk/refman-5.1/innodb.xml	2006-01-10 18:03:14 UTC (rev 757)
@@ -1445,10 +1445,12 @@
         </para>
 
         <para>
-          This value should currently be set to 0. Because recovery from
-          a backup is done by MySQL using its own log files, there is
-          currently no need to archive <literal>InnoDB</literal> log
-          files. The default for this variable is 0.
+          Whether to log <literal>InnoDB</literal> archive files. This
+          variable is present for historical reasons, but is unused.
+          Recovery from a backup is done by MySQL using its own log
+          files, so there is no need to archive
+          <literal>InnoDB</literal> log files. The default for this
+          variable is 0.
         </para>
       </listitem>
 
@@ -1493,7 +1495,7 @@
         <para>
           The number of log files in the log group.
           <literal>InnoDB</literal> writes to the files in a circular
-          fashion. The default is 2 (recommended).
+          fashion. The default (and recommended) is 2.
         </para>
       </listitem>
 
@@ -1522,14 +1524,8 @@
           This is an integer in the range from 0 to 100. The default is
           90. The main thread in <literal>InnoDB</literal> tries to
           write pages from the buffer pool so that the percentage of
-          dirty (not yet written) pages will not exceed this value. If
-          you have the <literal>SUPER</literal> privilege, this
-          percentage can be changed while the server is running:
+          dirty (not yet written) pages will not exceed this value.
         </para>
-
-<programlisting>
-SET GLOBAL innodb_max_dirty_pages_pct = <replaceable>value</replaceable>;
-</programlisting>
       </listitem>
 
       <listitem>
@@ -1540,10 +1536,9 @@
         <para>
           This variable controls how to delay <literal>INSERT</literal>,
           <literal>UPDATE</literal> and <literal>DELETE</literal>
-          operations when the purge operations (see
-          <xref linkend="innodb-multi-versioning"/>) are lagging. The
-          default value of this variable is 0, meaning that there are no
-          delays.
+          operations when the purge operations are lagging (see
+          <xref linkend="innodb-multi-versioning"/>). The default value
+          of this variable is 0, meaning that there are no delays.
         </para>
 
         <para>
@@ -1556,7 +1551,7 @@
           <literal>innodb_max_purge_lag</literal>, each
           <literal>INSERT</literal>, <literal>UPDATE</literal> and
           <literal>DELETE</literal> operation is delayed by
-          ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)*10)-5
+          ((<replaceable>purge_lag</replaceable>/<literal>innodb_max_purge_lag</literal>)&times;10)&minus;5
           milliseconds. The delay is computed in the beginning of a
           purge batch, every ten seconds. The operations are not delayed
           if purge cannot run because of an old consistent read view
@@ -1648,8 +1643,7 @@
           applications using <literal>AUTOCOMMIT=1</literal>,
           <literal>InnoDB</literal>'s internal table locks can cause
           deadlocks. You can set <literal>innodb_table_locks=0</literal>
-          in <filename>my.cnf</filename> (or <filename>my.ini</filename>
-          on Windows) to remove that problem.
+          in the server option file to remove that problem.
         </para>
       </listitem>
 
@@ -1676,20 +1670,17 @@
         </para>
       </listitem>
 
-<!--   
-        <listitem>
-        <remark role="todo">
-        document innodb_thread_sleep_delay
-        </remark>
-        
+      <listitem>
         <para>
-        <literal>innodb_thread_sleep_delay</literal>
+          <literal>innodb_thread_sleep_delay</literal>
         </para>
-        
+
         <para>
+          How long <literal>InnoDB</literal> threads sleep before
+          joining the <literal>InnoDB</literal> queue, in microseconds.
+          The default value is 10,000. A value of 0 disables sleep.
         </para>
-        </listitem>
-      -->
+      </listitem>
 
       <listitem>
         <para>

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