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

Log:
 r6057@frost:  paul | 2006-01-10 11:31:01 -0600
 General revisions.


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


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

Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml	2006-01-10 18:02:38 UTC (rev 755)
+++ trunk/refman-4.1/database-administration.xml	2006-01-10 18:02:56 UTC (rev 756)
@@ -7070,8 +7070,9 @@
             </para>
 
             <para>
-              If positive, the MySQL server synchronizes its binary log
-              to disk (<literal>fdatasync()</literal>) after every
+              If the value of this variable is positive, the MySQL
+              server synchronizes its binary log to disk
+              (<literal>fdatasync()</literal>) after every
               <literal>sync_binlog</literal>'th write to this binary
               log. Note that there is one write to the binary log per
               statement if in autocommit mode, and otherwise one write

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2006-01-10 18:02:38 UTC (rev 755)
+++ trunk/refman-4.1/innodb.xml	2006-01-10 18:02:56 UTC (rev 756)
@@ -1092,7 +1092,7 @@
         <para>
           The increment size (in MB) for extending the size of an
           auto-extending tablespace when it becomes full. The default
-          value is 8. This option is available starting from MySQL
+          value is 8. This variable is available starting from MySQL
           4.0.24 and 4.1.5. As of MySQL 4.0.24 and 4.1.6, it can be
           changed at runtime as a global system variable.
         </para>
@@ -1107,14 +1107,15 @@
           The size of the buffer pool (in MB), if it is placed in the
           AWE memory. This is relevant only in 32-bit Windows. If your
           32-bit Windows operating system supports more than 4GB memory,
-          so-called <quote>Address Windowing Extensions,</quote> you can
-          allocate the <literal>InnoDB</literal> buffer pool into the
-          AWE physical memory using this parameter. The maximum possible
-          value for this is 63000. If this parameter is specified,
-          <literal>innodb_buffer_pool_size</literal> is the window in
-          the 32-bit address space of <command>mysqld</command> where
-          <literal>InnoDB</literal> maps that AWE memory. A good value
-          for <literal>innodb_buffer_pool_size</literal> is 500MB. This
+          using so-called <quote>Address Windowing Extensions</quote>,
+          you can allocate the <literal>InnoDB</literal> buffer pool
+          into the AWE physical memory using this variable. The maximum
+          possible value for this variable is 63000. If it is greater
+          than 0, <literal>innodb_buffer_pool_size</literal> is the
+          window in the 32-bit address space of
+          <command>mysqld</command> where <literal>InnoDB</literal> maps
+          that AWE memory. A good value for
+          <literal>innodb_buffer_pool_size</literal> is 500MB. This
           variable is available as of MySQL 4.1.0.
         </para>
 
@@ -1188,12 +1189,12 @@
         </para>
 
         <para>
-          If you set this to 0, <literal>InnoDB</literal> does a full
-          purge and an insert buffer merge before a shutdown. These
-          operations can take minutes, or even hours in extreme cases.
-          If you set this parameter to 1, <literal>InnoDB</literal>
-          skips these operations at shutdown. The default value is 1
-          starting from 3.23.50.
+          If you set this variable to 0, <literal>InnoDB</literal> does
+          a full purge and an insert buffer merge before a shutdown.
+          These operations can take minutes, or even hours in extreme
+          cases. If you set this variable to 1,
+          <literal>InnoDB</literal> skips these operations at shutdown.
+          The default value is 1 starting from 3.23.50.
         </para>
       </listitem>
 
@@ -1207,8 +1208,8 @@
           Normally this should be left at the default value of 4, but
           disk I/O on Windows may benefit from a larger number. On Unix,
           increasing the number has no effect; <literal>InnoDB</literal>
-          always uses the default value. This option is available as of
-          MySQL 3.23.37.
+          always uses the default value. This variable is available as
+          of MySQL 3.23.37.
         </para>
       </listitem>
 
@@ -1232,11 +1233,12 @@
         </para>
 
         <para>
-          This option causes <literal>InnoDB</literal> to create each
-          new table using its own <filename>.ibd</filename> file for
-          storing data and indexes, rather than in the shared
+          If this variable is enabled, <literal>InnoDB</literal> creates
+          each new table using its own <filename>.ibd</filename> file
+          for storing data and indexes, rather than in the shared
+          tablespace. The default is to create tables in the shared
           tablespace. See <xref linkend="multiple-tablespaces"/>. This
-          option is available as of MySQL 4.1.1.
+          variable is available as of MySQL 4.1.1.
         </para>
       </listitem>
 
@@ -1247,42 +1249,48 @@
 
         <para>
           When <literal>innodb_flush_log_at_trx_commit</literal> is set
-          to 0, once per second the log buffer is written out to the log
-          file, and the flush to disk operation is performed on the log
+          to 0, the log buffer is written out to the log file once per
+          second and the flush to disk operation is performed on the log
           file, but nothing is done at a transaction commit. When this
-          value is 1 (the default), at each transaction commit the log
-          buffer is written out to the log file, and the flush to disk
-          operation is performed on the log file. When set to 2, at each
-          commit the log buffer is written out to the file, but the
+          value is 1 (the default), the log buffer is written out to the
+          log file at each transaction commit and the flush to disk
+          operation is performed on the log file. When set to 2, the log
+          buffer is written out to the file at each commit, but the
           flush to disk operation is not performed on it. However, the
-          flushing on the log file takes place once per second also in
-          the case of 2. We must note that the once-per-second flushing
-          is not 100% guaranteed to happen every second, due to process
-          scheduling issues. You can achieve better performance by
-          setting the value different from 1, but then you can lose at
-          most one second worth of transactions in a crash. If you set
-          the value to 0, then any <command>mysqld</command> process
-          crash can erase the last second of transactions. If you set
-          the value to 2, then only an operating system crash or a power
-          outage can erase the last second of transactions. However,
-          <literal>InnoDB</literal>'s crash recovery is not affected and
-          thus crash recovery does work regardless of the value. Note
-          that many operating systems and some disk hardware fool the
-          flush-to-disk operation. They may tell
-          <command>mysqld</command> that the flush has taken place,
-          though it has not. Then the durability of transactions is not
-          guaranteed even with the setting 1, and in the worst case a
-          power outage can even corrupt the <literal>InnoDB</literal>
-          database. Using a battery-backed disk cache in the SCSI disk
-          controller or in the disk itself speeds up file flushes, and
-          makes the operation safer. You can also try using the Unix
-          command <command>hdparm</command> to disable the caching of
-          disk writes in hardware caches, or use some other command
-          specific to the hardware vendor. The default value of this
-          option is 1 (prior to MySQL 4.0.13, the default is 0).
+          flushing on the log file takes place once per second also when
+          the value is 2. Note that the once-per-second flushing is not
+          100% guaranteed to happen every second, due to process
+          scheduling issues.
         </para>
 
         <para>
+          The default value of this variable is 1, which is the value
+          that is required for ACID compliance. You can achieve better
+          performance by setting the value different from 1, but then
+          you can lose at most one second worth of transactions in a
+          crash. If you set the value to 0, then any
+          <command>mysqld</command> process crash can erase the last
+          second of transactions. If you set the value to 2, then only
+          an operating system crash or a power outage can erase the last
+          second of transactions. However, <literal>InnoDB</literal>'s
+          crash recovery is not affected and thus crash recovery does
+          work regardless of the value. Note that many operating systems
+          and some disk hardware fool the flush-to-disk operation. They
+          may tell <command>mysqld</command> that the flush has taken
+          place, though it has not. Then the durability of transactions
+          is not guaranteed even with the setting 1, and in the worst
+          case a power outage can even corrupt the
+          <literal>InnoDB</literal> database. Using a battery-backed
+          disk cache in the SCSI disk controller or in the disk itself
+          speeds up file flushes, and makes the operation safer. You can
+          also try using the Unix command <command>hdparm</command> to
+          disable the caching of disk writes in hardware caches, or use
+          some other command specific to the hardware vendor. The
+          default value of this variable is 1 (prior to MySQL 4.0.13,
+          the default is 0).
+        </para>
+
+        <para>
           For the greatest possible durability and consistency in a
           replication setup you should use
           <literal>innodb_flush_log_at_trx_commit=1</literal>,
@@ -1313,8 +1321,10 @@
           <literal>fsync()</literal> instead of
           <literal>fdatasync()</literal>, and it does not use
           <literal>O_DSYNC</literal> by default because there have been
-          problems with them on many Unix flavors. This option is
-          available as of MySQL 3.23.40.
+          problems with it on many varieties of Unix. This variable is
+          relevant only for Unix. On Windows, the flush method is always
+          <literal>async_unbuffered</literal> and cannot be changed.
+          This variable is available as of MySQL 3.23.40.
         </para>
       </listitem>
 
@@ -1324,14 +1334,14 @@
         </para>
 
         <para>
-          Warning: This option should be defined only in an emergency
-          situation when you want to dump your tables from a corrupt
-          database! Possible values are from 1 to 6. The meanings of
-          these values are described in
+          The crash recovery mode. Warning: This variable should be set
+          greater than 0 only in an emergency situation when you want to
+          dump your tables from a corrupt database! Possible values are
+          from 1 to 6. The meanings of these values are described in
           <xref linkend="forcing-recovery"/>. As a safety measure,
-          <literal>InnoDB</literal> prevents a user from modifying data
-          when this option is greater than 0. This option is available
-          starting from MySQL 3.23.44.
+          <literal>InnoDB</literal> prevents any changes to its data
+          when this variable is greater than 0. This variable is
+          available starting from MySQL 3.23.44.
         </para>
       </listitem>
 
@@ -1420,10 +1430,10 @@
 
         <para>
           The directory where fully written log files would be archived
-          if we used log archiving. The value of this parameter should
+          if we used log archiving. The value of this variable should
           currently be set the same as
           <literal>innodb_log_group_home_dir</literal>. Starting from
-          MySQL 4.0.6, you may omit this option.
+          MySQL 4.0.6, there is no need to set this variable.
         </para>
       </listitem>
 
@@ -1436,7 +1446,7 @@
           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 option is 0.
+          default for this variable is 0.
         </para>
       </listitem>
 
@@ -1494,8 +1504,8 @@
           The directory path to the <literal>InnoDB</literal> log files.
           It must have the same value as
           <literal>innodb_log_arch_dir</literal>. If you do not specify
-          any <literal>InnoDB</literal> log parameters, the default is
-          to create two 5MB files names <filename>ib_logfile0</filename>
+          any <literal>InnoDB</literal> log variables, the default is to
+          create two 5MB files names <filename>ib_logfile0</filename>
           and <filename>ib_logfile1</filename> in the MySQL data
           directory.
         </para>
@@ -1527,15 +1537,13 @@
         </para>
 
         <para>
-          This option controls how to delay <literal>INSERT</literal>,
+          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 parameter is zero, meaning that there
-          are no delays. This option can be changed at runtime as a
-          global system variable.
-          <literal>innodb_max_purge_lag</literal> is available as of
-          MySQL 4.0.22 and 4.1.6.
+          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>
@@ -1580,11 +1588,11 @@
         </para>
 
         <para>
-          This option is relevant only if you use multiple tablespaces
+          This variable is relevant only if you use multiple tablespaces
           in <literal>InnoDB</literal>. It specifies the maximum number
           of <filename>.ibd</filename> files that
           <literal>InnoDB</literal> can keep open at one time. The
-          minimum value is 10. The default is 300. This option is
+          minimum value is 10. The default is 300. This variable is
           available as of MySQL 4.1.1.
         </para>
 
@@ -1647,16 +1655,16 @@
           <literal>InnoDB</literal> tries to keep the number of
           operating system threads concurrently inside
           <literal>InnoDB</literal> less than or equal to the limit
-          given by this parameter. The default value is 8. If you have
+          given by this variable. The default value is 8. If you have
           low performance and <literal>SHOW INNODB STATUS</literal>
           reveals many threads waiting for semaphores, you may have
-          thread thrashing and should try setting this parameter lower
-          or higher. If you have a computer with many processors and
-          disks, you can try setting the value higher to better utilize
-          the resources of your computer. A recommended value is the sum
-          of the number of processors and disks your system has. A value
-          of 500 or greater disables the concurrency checking. This
-          option is available starting from MySQL 3.23.44 and 4.0.1.
+          thread thrashing and should try setting this variable lower or
+          higher. If you have a computer with many processors and disks,
+          you can try setting the value higher to better utilize the
+          resources of your computer. A recommended value is the sum of
+          the number of processors and disks your system has. A value of
+          500 or greater disables the concurrency checking. This
+          variable is available starting from MySQL 3.23.44 and 4.0.1.
         </para>
       </listitem>
 
@@ -1666,8 +1674,9 @@
         </para>
 
         <para>
-          If positive, the MySQL server synchronizes its binary log to
-          disk (<literal>fdatasync()</literal>) after every
+          If the value of this variable is positive, the MySQL server
+          synchronizes its binary log to disk
+          (<literal>fdatasync()</literal>) after every
           <literal>sync_binlog</literal>'th write to this binary log.
           Note that there is one write to the binary log per statement
           if in autocommit mode, and otherwise one write per

Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml	2006-01-10 18:02:38 UTC (rev 755)
+++ trunk/refman-5.0/database-administration.xml	2006-01-10 18:02:56 UTC (rev 756)
@@ -8500,8 +8500,9 @@
             </para>
 
             <para>
-              If positive, the MySQL server synchronizes its binary log
-              to disk (<literal>fdatasync()</literal>) after every
+              If the value of this variable is positive, the MySQL
+              server synchronizes its binary log to disk
+              (<literal>fdatasync()</literal>) after every
               <literal>sync_binlog</literal>'th write to this binary
               log. Note that there is one write to the binary log per
               statement if in autocommit mode, and otherwise one write

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-10 18:02:38 UTC (rev 755)
+++ trunk/refman-5.0/innodb.xml	2006-01-10 18:02:56 UTC (rev 756)
@@ -997,9 +997,9 @@
           32-bit Windows operating system supports more than 4GB memory,
           using so-called <quote>Address Windowing Extensions</quote>,
           you can allocate the <literal>InnoDB</literal> buffer pool
-          into the AWE physical memory using this parameter. The maximum
-          possible value for this is 63000. If this parameter is
-          specified, <literal>innodb_buffer_pool_size</literal> is the
+          into the AWE physical memory using this variable. The maximum
+          possible value for this variable is 63000. If it is greater
+          than 0, <literal>innodb_buffer_pool_size</literal> is the
           window in the 32-bit address space of
           <command>mysqld</command> where <literal>InnoDB</literal> maps
           that AWE memory. A good value for
@@ -1055,8 +1055,8 @@
 
         <para>
           The number of threads that can commit at the same time. A
-          value of 0 disables concurrency control. This option was added
-          in MySQL 5.0.12.
+          value of 0 disables concurrency control. This variable was
+          added in MySQL 5.0.12.
         </para>
       </listitem>
 
@@ -1079,7 +1079,7 @@
           has used up its tickets. After that point, the thread again
           becomes subject to the concurrency check (and possible
           queuing) the next time it tries to enter
-          <literal>InnoDB</literal>. This option was added in MySQL
+          <literal>InnoDB</literal>. This variable was added in MySQL
           5.0.3.
         </para>
       </listitem>
@@ -1178,9 +1178,10 @@
         </para>
 
         <para>
-          This option causes <literal>InnoDB</literal> to create each
-          new table using its own <filename>.ibd</filename> file for
-          storing data and indexes, rather than in the shared
+          If this variable is enabled, <literal>InnoDB</literal> creates
+          each new table using its own <filename>.ibd</filename> file
+          for storing data and indexes, rather than in the shared
+          tablespace. The default is to create tables in the shared
           tablespace. See <xref linkend="multiple-tablespaces"/>.
         </para>
       </listitem>
@@ -1192,40 +1193,44 @@
 
         <para>
           When <literal>innodb_flush_log_at_trx_commit</literal> is set
-          to 0, once per second the log buffer is written out to the log
-          file, and the flush to disk operation is performed on the log
+          to 0, the log buffer is written out to the log file once per
+          second and the flush to disk operation is performed on the log
           file, but nothing is done at a transaction commit. When this
-          value is 1 (the default), at each transaction commit the log
-          buffer is written out to the log file, and the flush to disk
-          operation is performed on the log file. When set to 2, at each
-          commit the log buffer is written out to the file, but the
+          value is 1 (the default), the log buffer is written out to the
+          log file at each transaction commit and the flush to disk
+          operation is performed on the log file. When set to 2, the log
+          buffer is written out to the file at each commit, but the
           flush to disk operation is not performed on it. However, the
-          flushing on the log file takes place once per second also in
-          the case of 2. We must note that the once-per-second flushing
-          is not 100% guaranteed to happen every second, due to process
-          scheduling issues. You can achieve better performance by
-          setting the value different from 1, but then you can lose at
-          most one second worth of transactions in a crash. If you set
-          the value to 0, then any <command>mysqld</command> process
-          crash can erase the last second of transactions. If you set
-          the value to 2, then only an operating system crash or a power
-          outage can erase the last second of transactions. However,
-          <literal>InnoDB</literal>'s crash recovery is not affected and
-          thus crash recovery does work regardless of the value. Note
-          that many operating systems and some disk hardware fool the
-          flush-to-disk operation. They may tell
-          <command>mysqld</command> that the flush has taken place,
-          though it has not. Then the durability of transactions is not
-          guaranteed even with the setting 1, and in the worst case a
-          power outage can even corrupt the <literal>InnoDB</literal>
-          database. Using a battery-backed disk cache in the SCSI disk
-          controller or in the disk itself speeds up file flushes, and
-          makes the operation safer. You can also try using the Unix
-          command <command>hdparm</command> to disable the caching of
-          disk writes in hardware caches, or use some other command
-          specific to the hardware vendor. The default value of this
-          option is 1.
+          flushing on the log file takes place once per second also when
+          the value is 2. Note that the once-per-second flushing is not
+          100% guaranteed to happen every second, due to process
+          scheduling issues.
         </para>
+
+        <para>
+          The default value of this variable is 1, which is the value
+          that is required for ACID compliance. You can achieve better
+          performance by setting the value different from 1, but then
+          you can lose at most one second worth of transactions in a
+          crash. If you set the value to 0, then any
+          <command>mysqld</command> process crash can erase the last
+          second of transactions. If you set the value to 2, then only
+          an operating system crash or a power outage can erase the last
+          second of transactions. However, <literal>InnoDB</literal>'s
+          crash recovery is not affected and thus crash recovery does
+          work regardless of the value. Note that many operating systems
+          and some disk hardware fool the flush-to-disk operation. They
+          may tell <command>mysqld</command> that the flush has taken
+          place, though it has not. Then the durability of transactions
+          is not guaranteed even with the setting 1, and in the worst
+          case a power outage can even corrupt the
+          <literal>InnoDB</literal> database. Using a battery-backed
+          disk cache in the SCSI disk controller or in the disk itself
+          speeds up file flushes, and makes the operation safer. You can
+          also try using the Unix command <command>hdparm</command> to
+          disable the caching of disk writes in hardware caches, or use
+          some other command specific to the hardware vendor.
+        </para>
       </listitem>
 
       <listitem>
@@ -1248,7 +1253,9 @@
           <literal>fsync()</literal> instead of
           <literal>fdatasync()</literal>, and it does not use
           <literal>O_DSYNC</literal> by default because there have been
-          problems with this on many varieties of Unix.
+          problems with it on many varieties of Unix. This variable is
+          relevant only for Unix. On Windows, the flush method is always
+          <literal>async_unbuffered</literal> and cannot be changed.
         </para>
       </listitem>
 
@@ -1258,13 +1265,13 @@
         </para>
 
         <para>
-          Warning: This option should be defined only in an emergency
-          situation when you want to dump your tables from a corrupt
-          database! Possible values are from 1 to 6. The meanings of
-          these values are described in
+          The crash recovery mode. Warning: This variable should be set
+          greater than 0 only in an emergency situation when you want to
+          dump your tables from a corrupt database! Possible values are
+          from 1 to 6. The meanings of these values are described in
           <xref linkend="forcing-recovery"/>. As a safety measure,
-          <literal>InnoDB</literal> prevents a user from modifying data
-          when this option is greater than 0.
+          <literal>InnoDB</literal> prevents any changes to its data
+          when this variable is greater than 0.
         </para>
       </listitem>
 
@@ -1393,8 +1400,9 @@
           lock to the same row (2,3), which it cannot have. This is
           because query two first takes an exclusive lock on a row and
           then determines whether this row belongs to the result set,
-          and if not then releases the unnecessary lock, when the option
-          <literal>innodb_locks_unsafe_for_binlog</literal> is used.
+          and if not then releases the unnecessary lock, when the
+          <literal>innodb_locks_unsafe_for_binlog</literal> variable is
+          enabled.
         </para>
 
         <para>
@@ -1432,7 +1440,7 @@
 
         <para>
           The directory where fully written log files would be archived
-          if we used log archiving. If used, the value of this parameter
+          if we used log archiving. If used, the value of this variable
           should be set the same as
           <literal>innodb_log_group_home_dir</literal>. However, it is
           not required.
@@ -1448,7 +1456,7 @@
           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 option is 0.
+          files. The default for this variable is 0.
         </para>
       </listitem>
 
@@ -1506,8 +1514,8 @@
           The directory path to the <literal>InnoDB</literal> log files.
           It must have the same value as
           <literal>innodb_log_arch_dir</literal>. If you do not specify
-          any <literal>InnoDB</literal> log parameters, the default is
-          to create two 5MB files names <filename>ib_logfile0</filename>
+          any <literal>InnoDB</literal> log variables, the default is to
+          create two 5MB files names <filename>ib_logfile0</filename>
           and <filename>ib_logfile1</filename> in the MySQL data
           directory.
         </para>
@@ -1538,13 +1546,12 @@
         </para>
 
         <para>
-          This option controls how to delay <literal>INSERT</literal>,
+          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 parameter is zero, meaning that there
-          are no delays. This option can be changed at runtime as a
-          global system variable.
+          default value of this variable is 0, meaning that there are no
+          delays.
         </para>
 
         <para>
@@ -1589,7 +1596,7 @@
         </para>
 
         <para>
-          This option is relevant only if you use multiple tablespaces
+          This variable is relevant only if you use multiple tablespaces
           in <literal>InnoDB</literal>. It specifies the maximum number
           of <filename>.ibd</filename> files that
           <literal>InnoDB</literal> can keep open at one time. The
@@ -1645,7 +1652,7 @@
         <para>
           The number of times a thread waits for an
           <literal>InnoDB</literal> mutex to be freed before the thread
-          is suspended. This option was added in MySQL 5.0.3.
+          is suspended. This variable was added in MySQL 5.0.3.
         </para>
       </listitem>
 
@@ -1678,11 +1685,11 @@
           <literal>InnoDB</literal> tries to keep the number of
           operating system threads concurrently inside
           <literal>InnoDB</literal> less than or equal to the limit
-          given by this parameter. Before MySQL 5.0.8, the default value
+          given by this variable. Before MySQL 5.0.8, the default value
           is 8. If you have performance issues, and <literal>SHOW ENGINE
           INNODB STATUS</literal> reveals many threads waiting for
           semaphores, you may have thread <quote>thrashing</quote> and
-          should try setting this parameter lower or higher. If you have
+          should try setting this variable lower or higher. If you have
           a computer with many processors and disks, you can try setting
           the value higher to make better use of your computer's
           resources. A recommended value is the sum of the number of
@@ -1714,8 +1721,9 @@
         </para>
 
         <para>
-          If positive, the MySQL server synchronizes its binary log to
-          disk (<literal>fdatasync()</literal>) after every
+          If the value of this variable is positive, the MySQL server
+          synchronizes its binary log to disk
+          (<literal>fdatasync()</literal>) after every
           <literal>sync_binlog</literal>'th write to this binary log.
           Note that there is one write to the binary log per statement
           if in autocommit mode, and otherwise one write per

Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml	2006-01-10 18:02:38 UTC (rev 755)
+++ trunk/refman-5.1/database-administration.xml	2006-01-10 18:02:56 UTC (rev 756)
@@ -8467,8 +8467,9 @@
             </para>
 
             <para>
-              If positive, the MySQL server synchronizes its binary log
-              to disk (<literal>fdatasync()</literal>) after every
+              If the value of this variable is positive, the MySQL
+              server synchronizes its binary log to disk
+              (<literal>fdatasync()</literal>) after every
               <literal>sync_binlog</literal>'th write to this binary
               log. Note that there is one write to the binary log per
               statement if in autocommit mode, and otherwise one write

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-10 18:02:38 UTC (rev 755)
+++ trunk/refman-5.1/innodb.xml	2006-01-10 18:02:56 UTC (rev 756)
@@ -997,9 +997,9 @@
           32-bit Windows operating system supports more than 4GB memory,
           using so-called <quote>Address Windowing Extensions</quote>,
           you can allocate the <literal>InnoDB</literal> buffer pool
-          into the AWE physical memory using this parameter. The maximum
-          possible value for this is 63000. If this parameter is
-          specified, <literal>innodb_buffer_pool_size</literal> is the
+          into the AWE physical memory using this variable. The maximum
+          possible value for this variable is 63000. If it is greater
+          than 0, <literal>innodb_buffer_pool_size</literal> is the
           window in the 32-bit address space of
           <command>mysqld</command> where <literal>InnoDB</literal> maps
           that AWE memory. A good value for
@@ -1174,9 +1174,10 @@
         </para>
 
         <para>
-          This option causes <literal>InnoDB</literal> to create each
-          new table using its own <filename>.ibd</filename> file for
-          storing data and indexes, rather than in the shared
+          If this variable is enabled, <literal>InnoDB</literal> creates
+          each new table using its own <filename>.ibd</filename> file
+          for storing data and indexes, rather than in the shared
+          tablespace. The default is to create tables in the shared
           tablespace. See <xref linkend="multiple-tablespaces"/>.
         </para>
       </listitem>
@@ -1188,40 +1189,44 @@
 
         <para>
           When <literal>innodb_flush_log_at_trx_commit</literal> is set
-          to 0, once per second the log buffer is written out to the log
-          file, and the flush to disk operation is performed on the log
+          to 0, the log buffer is written out to the log file once per
+          second and the flush to disk operation is performed on the log
           file, but nothing is done at a transaction commit. When this
-          value is 1 (the default), at each transaction commit the log
-          buffer is written out to the log file, and the flush to disk
-          operation is performed on the log file. When set to 2, at each
-          commit the log buffer is written out to the file, but the
+          value is 1 (the default), the log buffer is written out to the
+          log file at each transaction commit and the flush to disk
+          operation is performed on the log file. When set to 2, the log
+          buffer is written out to the file at each commit, but the
           flush to disk operation is not performed on it. However, the
-          flushing on the log file takes place once per second also in
-          the case of 2. We must note that the once-per-second flushing
-          is not 100% guaranteed to happen every second, due to process
-          scheduling issues. You can achieve better performance by
-          setting the value different from 1, but then you can lose at
-          most one second worth of transactions in a crash. If you set
-          the value to 0, then any <command>mysqld</command> process
-          crash can erase the last second of transactions. If you set
-          the value to 2, then only an operating system crash or a power
-          outage can erase the last second of transactions. However,
-          <literal>InnoDB</literal>'s crash recovery is not affected and
-          thus crash recovery does work regardless of the value. Note
-          that many operating systems and some disk hardware fool the
-          flush-to-disk operation. They may tell
-          <command>mysqld</command> that the flush has taken place,
-          though it has not. Then the durability of transactions is not
-          guaranteed even with the setting 1, and in the worst case a
-          power outage can even corrupt the <literal>InnoDB</literal>
-          database. Using a battery-backed disk cache in the SCSI disk
-          controller or in the disk itself speeds up file flushes, and
-          makes the operation safer. You can also try using the Unix
-          command <command>hdparm</command> to disable the caching of
-          disk writes in hardware caches, or use some other command
-          specific to the hardware vendor. The default value of this
-          option is 1.
+          flushing on the log file takes place once per second also when
+          the value is 2. Note that the once-per-second flushing is not
+          100% guaranteed to happen every second, due to process
+          scheduling issues.
         </para>
+
+        <para>
+          The default value of this variable is 1, which is the value
+          that is required for ACID compliance. You can achieve better
+          performance by setting the value different from 1, but then
+          you can lose at most one second worth of transactions in a
+          crash. If you set the value to 0, then any
+          <command>mysqld</command> process crash can erase the last
+          second of transactions. If you set the value to 2, then only
+          an operating system crash or a power outage can erase the last
+          second of transactions. However, <literal>InnoDB</literal>'s
+          crash recovery is not affected and thus crash recovery does
+          work regardless of the value. Note that many operating systems
+          and some disk hardware fool the flush-to-disk operation. They
+          may tell <command>mysqld</command> that the flush has taken
+          place, though it has not. Then the durability of transactions
+          is not guaranteed even with the setting 1, and in the worst
+          case a power outage can even corrupt the
+          <literal>InnoDB</literal> database. Using a battery-backed
+          disk cache in the SCSI disk controller or in the disk itself
+          speeds up file flushes, and makes the operation safer. You can
+          also try using the Unix command <command>hdparm</command> to
+          disable the caching of disk writes in hardware caches, or use
+          some other command specific to the hardware vendor.
+        </para>
       </listitem>
 
       <listitem>
@@ -1244,7 +1249,9 @@
           <literal>fsync()</literal> instead of
           <literal>fdatasync()</literal>, and it does not use
           <literal>O_DSYNC</literal> by default because there have been
-          problems with this on many varieties of Unix.
+          problems with it on many varieties of Unix. This variable is
+          relevant only for Unix. On Windows, the flush method is always
+          <literal>async_unbuffered</literal> and cannot be changed.
         </para>
       </listitem>
 
@@ -1254,13 +1261,13 @@
         </para>
 
         <para>
-          Warning: This option should be defined only in an emergency
-          situation when you want to dump your tables from a corrupt
-          database! Possible values are from 1 to 6. The meanings of
-          these values are described in
+          The crash recovery mode. Warning: This variable should be set
+          greater than 0 only in an emergency situation when you want to
+          dump your tables from a corrupt database! Possible values are
+          from 1 to 6. The meanings of these values are described in
           <xref linkend="forcing-recovery"/>. As a safety measure,
-          <literal>InnoDB</literal> prevents a user from modifying data
-          when this option is greater than 0.
+          <literal>InnoDB</literal> prevents any changes to its data
+          when this variable is greater than 0.
         </para>
       </listitem>
 
@@ -1385,8 +1392,9 @@
           lock to the same row (2,3), which it cannot have. This is
           because query two first takes an exclusive lock on a row and
           then determines whether this row belongs to the result set,
-          and if not then releases the unnecessary lock, when the option
-          <literal>innodb_locks_unsafe_for_binlog</literal> is used.
+          and if not then releases the unnecessary lock, when the
+          <literal>innodb_locks_unsafe_for_binlog</literal> variable is
+          enabled.
         </para>
 
         <para>
@@ -1424,7 +1432,7 @@
 
         <para>
           The directory where fully written log files would be archived
-          if we used log archiving. If used, the value of this parameter
+          if we used log archiving. If used, the value of this variable
           should be set the same as
           <literal>innodb_log_group_home_dir</literal>. However, it is
           not required.
@@ -1440,7 +1448,7 @@
           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 option is 0.
+          files. The default for this variable is 0.
         </para>
       </listitem>
 
@@ -1498,8 +1506,8 @@
           The directory path to the <literal>InnoDB</literal> log files.
           It must have the same value as
           <literal>innodb_log_arch_dir</literal>. If you do not specify
-          any <literal>InnoDB</literal> log parameters, the default is
-          to create two 5MB files names <filename>ib_logfile0</filename>
+          any <literal>InnoDB</literal> log variables, the default is to
+          create two 5MB files names <filename>ib_logfile0</filename>
           and <filename>ib_logfile1</filename> in the MySQL data
           directory.
         </para>
@@ -1530,13 +1538,12 @@
         </para>
 
         <para>
-          This option controls how to delay <literal>INSERT</literal>,
+          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 parameter is zero, meaning that there
-          are no delays. This option can be changed at runtime as a
-          global system variable.
+          default value of this variable is 0, meaning that there are no
+          delays.
         </para>
 
         <para>
@@ -1581,7 +1588,7 @@
         </para>
 
         <para>
-          This option is relevant only if you use multiple tablespaces
+          This variable is relevant only if you use multiple tablespaces
           in <literal>InnoDB</literal>. It specifies the maximum number
           of <filename>.ibd</filename> files that
           <literal>InnoDB</literal> can keep open at one time. The
@@ -1655,10 +1662,10 @@
           <literal>InnoDB</literal> tries to keep the number of
           operating system threads concurrently inside
           <literal>InnoDB</literal> less than or equal to the limit
-          given by this parameter. If you have performance issues, and
+          given by this variable. If you have performance issues, and
           <literal>SHOW ENGINE INNODB STATUS</literal> reveals many
           threads waiting for semaphores, you may have thread
-          <quote>thrashing</quote> and should try setting this parameter
+          <quote>thrashing</quote> and should try setting this variable
           lower or higher. If you have a computer with many processors
           and disks, you can try setting the value higher to make better
           use of your computer's resources. A recommended value is the
@@ -1690,8 +1697,9 @@
         </para>
 
         <para>
-          If positive, the MySQL server synchronizes its binary log to
-          disk (<literal>fdatasync()</literal>) after every
+          If the value of this variable is positive, the MySQL server
+          synchronizes its binary log to disk
+          (<literal>fdatasync()</literal>) after every
           <literal>sync_binlog</literal>'th write to this binary log.
           Note that there is one write to the binary log per statement
           if in autocommit mode, and otherwise one write per

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