List:Commits« Previous MessageNext Message »
From:paul Date:January 10 2006 4:12am
Subject:svn commit - mysqldoc@docsrva: r750 - in trunk: . internals refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-10 05:12:27 +0100 (Tue, 10 Jan 2006)
New Revision: 750

Log:
 r6019@frost:  paul | 2006-01-09 22:10:39 -0600
 General revisions.


Modified:
   trunk/
   trunk/internals/fixedchars.ent
   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:6018
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6019
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994

Modified: trunk/internals/fixedchars.ent
===================================================================
--- trunk/internals/fixedchars.ent	2006-01-10 04:12:02 UTC (rev 749)
+++ trunk/internals/fixedchars.ent	2006-01-10 04:12:27 UTC (rev 750)
@@ -241,3 +241,6 @@
         <!ENTITY urcrop "&#x230E;">
         <!ENTITY pi     "&#x03D6;">
         <!ENTITY euro   "&#x20AC;">
+        <!ENTITY le     "&#x2264;">
+        <!ENTITY ge     "&#x2265;">
+        <!ENTITY ddash  "--">

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2006-01-10 04:12:02 UTC (rev 749)
+++ trunk/refman-4.1/innodb.xml	2006-01-10 04:12:27 UTC (rev 750)
@@ -1267,8 +1267,7 @@
         </para>
 
         <para>
-          This option is relevant only on Unix systems. If set to
-          <literal>fdatasync</literal> (the default),
+          If set to <literal>fdatasync</literal> (the default),
           <literal>InnoDB</literal> uses <literal>fsync()</literal> to
           flush both the data and log files. If set to
           <literal>O_DSYNC</literal>, <literal>InnoDB</literal> uses
@@ -4198,9 +4197,9 @@
       </para>
 
       <para>
-        If the locks to be set are exclusive, then
-        <literal>InnoDB</literal> always retrieves also the clustered
-        index record and sets a lock on it.
+        If the locks to be set are exclusive, <literal>InnoDB</literal>
+        always retrieves also the clustered index record and sets a lock
+        on it.
       </para>
 
       <para>
@@ -4212,6 +4211,11 @@
         rows.
       </para>
 
+      <para>
+        <literal>InnoDB</literal> sets specific types of locks as
+        follows:
+      </para>
+
       <itemizedlist>
 
         <listitem>
@@ -4262,7 +4266,7 @@
             auto-increment counter, <literal>InnoDB</literal> uses a
             specific table lock mode <literal>AUTO-INC</literal> where
             the lock lasts only to the end of the current SQL statement,
-            instead of to the end of the whole transaction. See
+            not to the end of the entire transaction. See
             <xref linkend="innodb-and-autocommit"/>.
           </para>
 
@@ -4328,9 +4332,9 @@
         <listitem>
           <para>
             If a <literal>FOREIGN KEY</literal> constraint is defined on
-            a table, any insert, update, or delete that requires
-            checking of the constraint condition sets shared
-            record-level locks on the records it looks at to check the
+            a table, any insert, update, or delete that requires the
+            constraint condition to be checked sets shared record-level
+            locks on the records that it looks at to check the
             constraint. <literal>InnoDB</literal> also sets these locks
             in the case where the constraint fails.
           </para>
@@ -4342,7 +4346,7 @@
             the higher MySQL layer above the <literal>InnoDB</literal>
             layer that sets these locks. Beginning with MySQL 4.0.20 and
             4.1.2, <literal>InnoDB</literal> is aware of table locks if
-            <literal>innodb_table_locks=1</literal> and
+            <literal>innodb_table_locks=1</literal> (the default) and
             <literal>AUTOCOMMIT=0</literal>, and the MySQL layer above
             <literal>InnoDB</literal> knows about row-level locks.
             Otherwise, InnoDB's automatic deadlock detection cannot
@@ -4370,24 +4374,20 @@
       </remark>
 
       <para>
-        MySQL begins each client connection with autocommit mode enabled
-        by default. When autocommit is enabled, MySQL does a commit
+        By default, MySQL begins each client connection with autocommit
+        mode enabled. When autocommit is enabled, MySQL does a commit
         after each SQL statement if that statement did not return an
-        error.
+        error. If an SQL statement returns an error, the commit or
+        rollback behavior depends on the error. See
+        <xref linkend="innodb-error-handling"/>.
       </para>
 
       <para>
         If you have the autocommit mode off and close a connection
-        without calling an explicit commit of your transaction, then
-        MySQL rolls back your transaction.
+        without explicitly committing the final transaction, MySQL rolls
+        back that transaction.
       </para>
 
-      <para>
-        If an SQL statement returns an error, the commit or rollback
-        behavior depends on the error. See
-        <xref linkend="innodb-error-handling"/>.
-      </para>
-
       <remark role="note">
         The following material also appears in id="implicit-commit".
         Edits should be made to both sections.
@@ -4462,10 +4462,10 @@
       <para>
         <literal>InnoDB</literal> automatically detects a deadlock of
         transactions and rolls back a transaction or transactions to
-        prevent the deadlock. Starting from MySQL 4.0.5,
+        break the deadlock. Starting from MySQL 4.0.5,
         <literal>InnoDB</literal> tries to pick small transactions to
-        roll back. The size of a transaction is determined by the number
-        of rows it has inserted, updated, or deleted. Prior to 4.0.5,
+        roll back, the size of a transaction being determined by the
+        number of rows inserted, updated, or deleted. Prior to 4.0.5,
         <literal>InnoDB</literal> always rolled back the transaction
         whose lock request was the last one to build a deadlock, that
         is, a cycle in the <quote>waits-for</quote> graph of
@@ -4475,25 +4475,25 @@
       <para>
         Beginning with MySQL 4.0.20 and 4.1.2, <literal>InnoDB</literal>
         is aware of table locks if
-        <literal>innodb_table_locks=1</literal> (1 is the default), and
-        the MySQL layer above <literal>InnoDB</literal> knows about
-        row-level locks. Before that, <literal>InnoDB</literal> cannot
-        detect deadlocks where a table lock set by a MySQL <literal>LOCK
-        TABLES</literal> statement is involved, or if a lock set by
-        another storage engine than <literal>InnoDB</literal> is
-        involved. You have to resolve these situations by setting the
-        value of the <literal>innodb_lock_wait_timeout</literal> system
-        variable.
+        <literal>innodb_table_locks=1</literal> (the default) and
+        <literal>AUTOCOMMIT=0</literal>, and the MySQL layer above
+        <literal>InnoDB</literal> knows about row-level locks. Before
+        that, <literal>InnoDB</literal> cannot detect deadlocks where a
+        table lock set by a MySQL <literal>LOCK TABLES</literal>
+        statement is involved, or if a lock set by another storage
+        engine than <literal>InnoDB</literal> is involved. You have to
+        resolve these situations by setting the value of the
+        <literal>innodb_lock_wait_timeout</literal> system variable.
       </para>
 
       <para>
         When <literal>InnoDB</literal> performs a complete rollback of a
-        transaction, all the locks of the transaction are released.
+        transaction, all locks set by the transaction are released.
         However, if just a single SQL statement is rolled back as a
-        result of an error, some of the locks set by the SQL statement
-        may be preserved. This happens because <literal>InnoDB</literal>
-        stores row locks in a format such it cannot know afterward which
-        lock was set by which SQL statement.
+        result of an error, some of the locks set by the statement may
+        be preserved. This happens because <literal>InnoDB</literal>
+        stores row locks in a format such that it cannot know afterward
+        which lock was set by which statement.
       </para>
 
     </section>
@@ -4547,7 +4547,7 @@
         <listitem>
           <para>
             Commit your transactions often. Small transactions are less
-            prone to collide.
+            prone to collision.
           </para>
         </listitem>
 
@@ -4593,18 +4593,19 @@
           <para>
             If nothing else helps, serialize your transactions with
             table-level locks. The correct way to use <literal>LOCK
-            TABLES</literal> with transactional tables, like
-            <literal>InnoDB</literal>, is to set <literal>AUTOCOMMIT =
-            0</literal> and not to call <literal>UNLOCK TABLES</literal>
-            until you commit the transaction explicitly. For example, if
-            you need to write to table <literal>t1</literal> and read
-            from table <literal>t2</literal>, you can do this:
+            TABLES</literal> with transactional tables, such as
+            <literal>InnoDB</literal> tables, is to set
+            <literal>AUTOCOMMIT = 0</literal> and not to call
+            <literal>UNLOCK TABLES</literal> until after you commit the
+            transaction explicitly. For example, if you need to write to
+            table <literal>t1</literal> and read from table
+            <literal>t2</literal>, you can do this:
           </para>
 
 <programlisting>
 SET AUTOCOMMIT=0;
 LOCK TABLES t1 WRITE, t2 READ, ...;
-[do something with tables t1 and t2 here];
+<replaceable>... do something with tables t1 and t2 here ...</replaceable>
 COMMIT;
 UNLOCK TABLES;
 </programlisting>
@@ -4631,7 +4632,7 @@
 
         <listitem>
           <para>
-            In applications using <literal>AUTOCOMMIT=1</literal> and
+            In applications that use <literal>AUTOCOMMIT=1</literal> and
             MySQL's <literal>LOCK TABLES</literal> command,
             <literal>InnoDB</literal>'s internal table locks that were
             present from 4.0.20 to 4.0.23 can cause deadlocks. Starting
@@ -4687,8 +4688,8 @@
       <listitem>
         <para>
           If you can afford the loss of some of the latest committed
-          transactions, you can set the <filename>my.cnf</filename>
-          parameter <literal>innodb_flush_log_at_trx_commit</literal> to
+          transactions if a crash occurs, you can set the
+          <literal>innodb_flush_log_at_trx_commit</literal> parameter to
           0. <literal>InnoDB</literal> tries to flush the log once per
           second anyway, although the flush is not guaranteed.
         </para>
@@ -4718,8 +4719,8 @@
           strings or if the column may contain many
           <literal>NULL</literal> values. A
           <literal>CHAR(<replaceable>N</replaceable>)</literal> column
-          always takes <replaceable>N</replaceable> bytes to store data,
-          even if the string is shorter or its value is
+          always takes <replaceable>N</replaceable> characters to store
+          data, even if the string is shorter or its value is
           <literal>NULL</literal>. Smaller tables fit better in the
           buffer pool and reduce disk I/O.
         </para>
@@ -4729,15 +4730,14 @@
         <para>
           (Relevant from 3.23.39 up.) In some versions of GNU/Linux and
           Unix, flushing files to disk with the Unix
-          <literal>fsync()</literal> and other similar methods is
-          surprisingly slow. The default method
-          <literal>InnoDB</literal> uses is the
-          <literal>fsync()</literal> function. If you are not satisfied
-          with the database write performance, you might try setting
-          <literal>innodb_flush_method</literal> in
-          <filename>my.cnf</filename> to <literal>O_DSYNC</literal>,
-          although <literal>O_DSYNC</literal> seems to be slower on most
-          systems.
+          <literal>fsync()</literal> call (which
+          <literal>InnoDB</literal> uses by default) and other similar
+          methods is surprisingly slow. If you are dissatisfied with
+          database write performance, you might try setting the
+          <literal>innodb_flush_method</literal> parameter to
+          <literal>O_DSYNC</literal>. Although
+          <literal>O_DSYNC</literal> seems to be slower on most systems,
+          yours might not be one of them.
         </para>
       </listitem>
 
@@ -4751,28 +4751,28 @@
           <literal>InnoDB</literal>-related files using the
           <literal>forcedirectio</literal> option. (The default on
           Solaris 10/x86_64 is <emphasis>not</emphasis> to use this
-          filesystem mounting option.) Failing to use
-          <literal>forcedirectio</literal> will cause a serious
-          degradation of <literal>InnoDB</literal>'s speed and
-          performance on this platform.
+          option.) Failure to use <literal>forcedirectio</literal>
+          causes a serious degradation of <literal>InnoDB</literal>'s
+          speed and performance on this platform.
         </para>
 
         <para>
           When using the <literal>InnoDB</literal> storage engine with a
           large <literal>innodb_buffer_pool_size</literal> value on any
-          release Solaris &ge; 2.6 and any platform
+          release of Solaris 2.6 and up and any platform
           (sparc/x86/x64/amd64), a significant performance gain can be
           achieved by placing <literal>InnoDB</literal> data files and
           log files on raw devices or on a separate direct I/O UFS
-          Filesystem (mount option <literal>forcedirectio</literal>; see
+          filesystem (using mount option
+          <literal>forcedirectio</literal>; see
           <literal>mount_ufs(1M)</literal>). Users of the Veritas
           filesystem VxFS should use the mount option
           <literal>convosync=direct</literal>.
         </para>
 
         <para>
-          Other MySQL data files such as those for
-          <literal>MyISAM</literal> tables should not be placed on a
+          Other MySQL data files, such as those for
+          <literal>MyISAM</literal> tables, should not be placed on a
           direct I/O filesystem. Executables or libraries <emphasis>must
           not</emphasis> be placed on a direct I/O filesystem.
         </para>
@@ -4782,7 +4782,7 @@
         <para>
           When importing data into <literal>InnoDB</literal>, make sure
           that MySQL does not have autocommit mode enabled because that
-          would require a log flush to disk for every insert. To disable
+          requires a log flush to disk for every insert. To disable
           autocommit during your import operation, surround it with
           <literal>SET AUTOCOMMIT</literal> and
           <literal>COMMIT</literal> statements:
@@ -4790,7 +4790,7 @@
 
 <programlisting>
 SET AUTOCOMMIT=0;
-/* SQL import statements ... */
+<replaceable>... SQL import statements ...</replaceable>
 COMMIT;
 </programlisting>
 
@@ -7056,14 +7056,13 @@
         <para>
           Beginning with MySQL 4.0.20 and 4.1.2, the MySQL <literal>LOCK
           TABLES</literal> operation acquires two locks on each table if
-          <literal>innodb_table_locks=1</literal>. (1 is the default.)
-          In addition to a table lock on the MySQL layer, it also
-          acquires an <literal>InnoDB</literal> table lock. Older
-          versions of MySQL do not acquire <literal>InnoDB</literal>
-          table locks. Beginning with MySQL 4.0.22 and 4.1.7, the old
-          behavior can be selected by setting
-          <literal>innodb_table_locks=0</literal>. If no
-          <literal>InnoDB</literal> table lock is acquired,
+          <literal>innodb_table_locks=1</literal> (the default). In
+          addition to a table lock on the MySQL layer, it also acquires
+          an <literal>InnoDB</literal> table lock. Older versions of
+          MySQL do not acquire <literal>InnoDB</literal> table locks.
+          Beginning with MySQL 4.0.22 and 4.1.7, the old behavior can be
+          selected by setting <literal>innodb_table_locks=0</literal>.
+          If no <literal>InnoDB</literal> table lock is acquired,
           <literal>LOCK TABLES</literal> completes even if some records
           of the tables are being locked by other transactions.
         </para>

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-10 04:12:02 UTC (rev 749)
+++ trunk/refman-5.0/innodb.xml	2006-01-10 04:12:27 UTC (rev 750)
@@ -1191,8 +1191,7 @@
         </para>
 
         <para>
-          This option is relevant only on Unix systems. If set to
-          <literal>fdatasync</literal> (the default),
+          If set to <literal>fdatasync</literal> (the default),
           <literal>InnoDB</literal> uses <literal>fsync()</literal> to
           flush both the data and log files. If set to
           <literal>O_DSYNC</literal>, <literal>InnoDB</literal> uses
@@ -4141,9 +4140,9 @@
       </para>
 
       <para>
-        If the locks to be set are exclusive, then
-        <literal>InnoDB</literal> always retrieves also the clustered
-        index record and sets a lock on it.
+        If the locks to be set are exclusive, <literal>InnoDB</literal>
+        always retrieves also the clustered index record and sets a lock
+        on it.
       </para>
 
       <para>
@@ -4155,6 +4154,11 @@
         rows.
       </para>
 
+      <para>
+        <literal>InnoDB</literal> sets specific types of locks as
+        follows:
+      </para>
+
       <itemizedlist>
 
         <listitem>
@@ -4205,7 +4209,7 @@
             auto-increment counter, <literal>InnoDB</literal> uses a
             specific table lock mode <literal>AUTO-INC</literal> where
             the lock lasts only to the end of the current SQL statement,
-            instead of to the end of the whole transaction. See
+            not to the end of the entire transaction. See
             <xref linkend="innodb-and-autocommit"/>.
           </para>
 
@@ -4264,9 +4268,9 @@
         <listitem>
           <para>
             If a <literal>FOREIGN KEY</literal> constraint is defined on
-            a table, any insert, update, or delete that requires
-            checking of the constraint condition sets shared
-            record-level locks on the records it looks at to check the
+            a table, any insert, update, or delete that requires the
+            constraint condition to be checked sets shared record-level
+            locks on the records that it looks at to check the
             constraint. <literal>InnoDB</literal> also sets these locks
             in the case where the constraint fails.
           </para>
@@ -4278,7 +4282,7 @@
             the higher MySQL layer above the <literal>InnoDB</literal>
             layer that sets these locks. <literal>InnoDB</literal> is
             aware of table locks if
-            <literal>innodb_table_locks=1</literal> and
+            <literal>innodb_table_locks=1</literal> (the default) and
             <literal>AUTOCOMMIT=0</literal>, and the MySQL layer above
             <literal>InnoDB</literal> knows about row-level locks.
             Otherwise, <literal>InnoDB</literal>'s automatic deadlock
@@ -4306,24 +4310,20 @@
       </remark>
 
       <para>
-        MySQL begins each client connection with autocommit mode enabled
-        by default. When autocommit is enabled, MySQL does a commit
+        By default, MySQL begins each client connection with autocommit
+        mode enabled. When autocommit is enabled, MySQL does a commit
         after each SQL statement if that statement did not return an
-        error.
+        error. If an SQL statement returns an error, the commit or
+        rollback behavior depends on the error. See
+        <xref linkend="innodb-error-handling"/>.
       </para>
 
       <para>
         If you have the autocommit mode off and close a connection
-        without calling an explicit commit of your transaction, then
-        MySQL rolls back your transaction.
+        without explicitly committing the final transaction, MySQL rolls
+        back that transaction.
       </para>
 
-      <para>
-        If an SQL statement returns an error, the commit or rollback
-        behavior depends on the error. See
-        <xref linkend="innodb-error-handling"/>.
-      </para>
-
       <remark role="note">
         The following material also appears in id="implicit-commit".
         Edits should be made to both sections.
@@ -4407,15 +4407,17 @@
       <para>
         <literal>InnoDB</literal> automatically detects a deadlock of
         transactions and rolls back a transaction or transactions to
-        prevent the deadlock. <literal>InnoDB</literal> tries to pick
-        small transactions to roll back, the size of a transaction being
-        determined by the number of rows inserted, updated, or deleted.
+        break the deadlock. <literal>InnoDB</literal> tries to pick
+        small transactions to roll back, where the size of a transaction
+        is determined by the number of rows inserted, updated, or
+        deleted.
       </para>
 
       <para>
         <literal>InnoDB</literal> is aware of table locks if
-        <literal>innodb_table_locks=1</literal> (1 is the default), and
-        the MySQL layer above it knows about row-level locks. Otherwise,
+        <literal>innodb_table_locks=1</literal> (the default) and
+        <literal>AUTOCOMMIT=0</literal>, and the MySQL layer above it
+        knows about row-level locks. Otherwise,
         <literal>InnoDB</literal> cannot detect deadlocks where a table
         lock set by a MySQL <literal>LOCK TABLES</literal> statement or
         a lock set by a storage engine other than
@@ -4426,12 +4428,12 @@
 
       <para>
         When <literal>InnoDB</literal> performs a complete rollback of a
-        transaction, all the locks of the transaction are released.
+        transaction, all locks set by the transaction are released.
         However, if just a single SQL statement is rolled back as a
-        result of an error, some of the locks set by the SQL statement
-        may be preserved. This happens because <literal>InnoDB</literal>
-        stores row locks in a format such it cannot know afterward which
-        lock was set by which SQL statement.
+        result of an error, some of the locks set by the statement may
+        be preserved. This happens because <literal>InnoDB</literal>
+        stores row locks in a format such that it cannot know afterward
+        which lock was set by which statement.
       </para>
 
     </section>
@@ -4482,7 +4484,7 @@
         <listitem>
           <para>
             Commit your transactions often. Small transactions are less
-            prone to collide.
+            prone to collision.
           </para>
         </listitem>
 
@@ -4528,18 +4530,19 @@
           <para>
             If nothing else helps, serialize your transactions with
             table-level locks. The correct way to use <literal>LOCK
-            TABLES</literal> with transactional tables, like
-            <literal>InnoDB</literal>, is to set <literal>AUTOCOMMIT =
-            0</literal> and not to call <literal>UNLOCK TABLES</literal>
-            until you commit the transaction explicitly. For example, if
-            you need to write to table <literal>t1</literal> and read
-            from table <literal>t2</literal>, you can do this:
+            TABLES</literal> with transactional tables, such as
+            <literal>InnoDB</literal> tables, is to set
+            <literal>AUTOCOMMIT = 0</literal> and not to call
+            <literal>UNLOCK TABLES</literal> until after you commit the
+            transaction explicitly. For example, if you need to write to
+            table <literal>t1</literal> and read from table
+            <literal>t2</literal>, you can do this:
           </para>
 
 <programlisting>
 SET AUTOCOMMIT=0;
 LOCK TABLES t1 WRITE, t2 READ, ...;
-[do something with tables t1 and t2 here];
+<replaceable>... do something with tables t1 and t2 here ...</replaceable>
 COMMIT;
 UNLOCK TABLES;
 </programlisting>
@@ -4566,7 +4569,7 @@
 
         <listitem>
           <para>
-            In applications using the <literal>LOCK TABLES</literal>
+            In applications that use the <literal>LOCK TABLES</literal>
             command, MySQL does not set <literal>InnoDB</literal> table
             locks if <literal>AUTOCOMMIT=1</literal>.
           </para>
@@ -4615,8 +4618,8 @@
       <listitem>
         <para>
           If you can afford the loss of some of the latest committed
-          transactions, you can set the <filename>my.cnf</filename>
-          parameter <literal>innodb_flush_log_at_trx_commit</literal> to
+          transactions if a crash occurs, you can set the
+          <literal>innodb_flush_log_at_trx_commit</literal> parameter to
           0. <literal>InnoDB</literal> tries to flush the log once per
           second anyway, although the flush is not guaranteed.
         </para>
@@ -4646,8 +4649,8 @@
           strings or if the column may contain many
           <literal>NULL</literal> values. A
           <literal>CHAR(<replaceable>N</replaceable>)</literal> column
-          always takes <replaceable>N</replaceable> bytes to store data,
-          even if the string is shorter or its value is
+          always takes <replaceable>N</replaceable> characters to store
+          data, even if the string is shorter or its value is
           <literal>NULL</literal>. Smaller tables fit better in the
           buffer pool and reduce disk I/O.
         </para>
@@ -4666,14 +4669,14 @@
       <listitem>
         <para>
           In some versions of GNU/Linux and Unix, flushing files to disk
-          with the Unix <literal>fsync()</literal> (which
+          with the Unix <literal>fsync()</literal> call (which
           <literal>InnoDB</literal> uses by default) and other similar
           methods is surprisingly slow. If you are dissatisfied with
-          database write performance, you might try setting
-          <literal>innodb_flush_method</literal> in
-          <filename>my.cnf</filename> to <literal>O_DSYNC</literal>,
-          although <literal>O_DSYNC</literal> seems to be slower on most
-          systems.
+          database write performance, you might try setting the
+          <literal>innodb_flush_method</literal> parameter to
+          <literal>O_DSYNC</literal>. Although
+          <literal>O_DSYNC</literal> seems to be slower on most systems,
+          yours might not be one of them.
         </para>
       </listitem>
 
@@ -4685,28 +4688,28 @@
           <literal>InnoDB</literal>-related files using the
           <literal>forcedirectio</literal> option. (The default on
           Solaris 10/x86_64 is <emphasis>not</emphasis> to use this
-          filesystem mounting option.) Failing to use
-          <literal>forcedirectio</literal> will cause a serious
-          degradation of <literal>InnoDB</literal>'s speed and
-          performance on this platform.
+          option.) Failure to use <literal>forcedirectio</literal>
+          causes a serious degradation of <literal>InnoDB</literal>'s
+          speed and performance on this platform.
         </para>
 
         <para>
           When using the <literal>InnoDB</literal> storage engine with a
           large <literal>innodb_buffer_pool_size</literal> value on any
-          release Solaris &ge; 2.6 and any platform
+          release of Solaris 2.6 and up and any platform
           (sparc/x86/x64/amd64), a significant performance gain can be
           achieved by placing <literal>InnoDB</literal> data files and
           log files on raw devices or on a separate direct I/O UFS
-          Filesystem (mount option <literal>forcedirectio</literal>; see
+          filesystem (using mount option
+          <literal>forcedirectio</literal>; see
           <literal>mount_ufs(1M)</literal>). Users of the Veritas
           filesystem VxFS should use the mount option
           <literal>convosync=direct</literal>.
         </para>
 
         <para>
-          Other MySQL data files such as those for
-          <literal>MyISAM</literal> tables should not be placed on a
+          Other MySQL data files, such as those for
+          <literal>MyISAM</literal> tables, should not be placed on a
           direct I/O filesystem. Executables or libraries <emphasis>must
           not</emphasis> be placed on a direct I/O filesystem.
         </para>
@@ -4716,7 +4719,7 @@
         <para>
           When importing data into <literal>InnoDB</literal>, make sure
           that MySQL does not have autocommit mode enabled because that
-          would require a log flush to disk for every insert. To disable
+          requires a log flush to disk for every insert. To disable
           autocommit during your import operation, surround it with
           <literal>SET AUTOCOMMIT</literal> and
           <literal>COMMIT</literal> statements:
@@ -4724,7 +4727,7 @@
 
 <programlisting>
 SET AUTOCOMMIT=0;
-/* SQL import statements ... */
+<replaceable>... SQL import statements ...</replaceable>
 COMMIT;
 </programlisting>
 
@@ -6971,11 +6974,11 @@
         <para>
           In MySQL &current-series;, the MySQL <literal>LOCK
           TABLES</literal> operation acquires two locks on each table if
-          <literal>innodb_table_locks=1</literal>, with 1 being the
-          default.) In addition to a table lock on the MySQL layer, it
-          also acquires an <literal>InnoDB</literal> table lock. Older
-          versions of MySQL did not acquire <literal>InnoDB</literal>
-          table locks; the old behavior can be selected by setting
+          <literal>innodb_table_locks=1</literal> (the default). In
+          addition to a table lock on the MySQL layer, it also acquires
+          an <literal>InnoDB</literal> table lock. Older versions of
+          MySQL did not acquire <literal>InnoDB</literal> table locks;
+          the old behavior can be selected by setting
           <literal>innodb_table_locks=0</literal>. If no
           <literal>InnoDB</literal> table lock is acquired,
           <literal>LOCK TABLES</literal> completes even if some records

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-10 04:12:02 UTC (rev 749)
+++ trunk/refman-5.1/innodb.xml	2006-01-10 04:12:27 UTC (rev 750)
@@ -1188,8 +1188,7 @@
         </para>
 
         <para>
-          This option is relevant only on Unix systems. If set to
-          <literal>fdatasync</literal> (the default),
+          If set to <literal>fdatasync</literal> (the default),
           <literal>InnoDB</literal> uses <literal>fsync()</literal> to
           flush both the data and log files. If set to
           <literal>O_DSYNC</literal>, <literal>InnoDB</literal> uses
@@ -4117,9 +4116,9 @@
       </para>
 
       <para>
-        If the locks to be set are exclusive, then
-        <literal>InnoDB</literal> always retrieves also the clustered
-        index record and sets a lock on it.
+        If the locks to be set are exclusive, <literal>InnoDB</literal>
+        always retrieves also the clustered index record and sets a lock
+        on it.
       </para>
 
       <para>
@@ -4131,6 +4130,11 @@
         rows.
       </para>
 
+      <para>
+        <literal>InnoDB</literal> sets specific types of locks as
+        follows:
+      </para>
+
       <itemizedlist>
 
         <listitem>
@@ -4181,7 +4185,7 @@
             auto-increment counter, <literal>InnoDB</literal> uses a
             specific table lock mode <literal>AUTO-INC</literal> where
             the lock lasts only to the end of the current SQL statement,
-            instead of to the end of the whole transaction. See
+            not to the end of the entire transaction. See
             <xref linkend="innodb-and-autocommit"/>.
           </para>
 
@@ -4240,9 +4244,9 @@
         <listitem>
           <para>
             If a <literal>FOREIGN KEY</literal> constraint is defined on
-            a table, any insert, update, or delete that requires
-            checking of the constraint condition sets shared
-            record-level locks on the records it looks at to check the
+            a table, any insert, update, or delete that requires the
+            constraint condition to be checked sets shared record-level
+            locks on the records that it looks at to check the
             constraint. <literal>InnoDB</literal> also sets these locks
             in the case where the constraint fails.
           </para>
@@ -4254,7 +4258,7 @@
             the higher MySQL layer above the <literal>InnoDB</literal>
             layer that sets these locks. <literal>InnoDB</literal> is
             aware of table locks if
-            <literal>innodb_table_locks=1</literal> and
+            <literal>innodb_table_locks=1</literal> (the default) and
             <literal>AUTOCOMMIT=0</literal>, and the MySQL layer above
             <literal>InnoDB</literal> knows about row-level locks.
             Otherwise, <literal>InnoDB</literal>'s automatic deadlock
@@ -4282,24 +4286,20 @@
       </remark>
 
       <para>
-        MySQL begins each client connection with autocommit mode enabled
-        by default. When autocommit is enabled, MySQL does a commit
+        By default, MySQL begins each client connection with autocommit
+        mode enabled. When autocommit is enabled, MySQL does a commit
         after each SQL statement if that statement did not return an
-        error.
+        error. If an SQL statement returns an error, the commit or
+        rollback behavior depends on the error. See
+        <xref linkend="innodb-error-handling"/>.
       </para>
 
       <para>
         If you have the autocommit mode off and close a connection
-        without calling an explicit commit of your transaction, then
-        MySQL rolls back your transaction.
+        without explicitly committing the final transaction, MySQL rolls
+        back that transaction.
       </para>
 
-      <para>
-        If an SQL statement returns an error, the commit or rollback
-        behavior depends on the error. See
-        <xref linkend="innodb-error-handling"/>.
-      </para>
-
       <remark role="note">
         The following material also appears in id="implicit-commit".
         Edits should be made to both sections.
@@ -4368,15 +4368,17 @@
       <para>
         <literal>InnoDB</literal> automatically detects a deadlock of
         transactions and rolls back a transaction or transactions to
-        prevent the deadlock. <literal>InnoDB</literal> tries to pick
-        small transactions to roll back, the size of a transaction being
-        determined by the number of rows inserted, updated, or deleted.
+        break the deadlock. <literal>InnoDB</literal> tries to pick
+        small transactions to roll back, where the size of a transaction
+        is determined by the number of rows inserted, updated, or
+        deleted.
       </para>
 
       <para>
         <literal>InnoDB</literal> is aware of table locks if
-        <literal>innodb_table_locks=1</literal> (1 is the default), and
-        the MySQL layer above it knows about row-level locks. Otherwise,
+        <literal>innodb_table_locks=1</literal> (the default) and
+        <literal>AUTOCOMMIT=0</literal>, and the MySQL layer above it
+        knows about row-level locks. Otherwise,
         <literal>InnoDB</literal> cannot detect deadlocks where a table
         lock set by a MySQL <literal>LOCK TABLES</literal> statement or
         a lock set by a storage engine other than
@@ -4387,12 +4389,12 @@
 
       <para>
         When <literal>InnoDB</literal> performs a complete rollback of a
-        transaction, all the locks of the transaction are released.
+        transaction, all locks set by the transaction are released.
         However, if just a single SQL statement is rolled back as a
-        result of an error, some of the locks set by the SQL statement
-        may be preserved. This happens because <literal>InnoDB</literal>
-        stores row locks in a format such it cannot know afterward which
-        lock was set by which SQL statement.
+        result of an error, some of the locks set by the statement may
+        be preserved. This happens because <literal>InnoDB</literal>
+        stores row locks in a format such that it cannot know afterward
+        which lock was set by which statement.
       </para>
 
     </section>
@@ -4443,7 +4445,7 @@
         <listitem>
           <para>
             Commit your transactions often. Small transactions are less
-            prone to collide.
+            prone to collision.
           </para>
         </listitem>
 
@@ -4489,18 +4491,19 @@
           <para>
             If nothing else helps, serialize your transactions with
             table-level locks. The correct way to use <literal>LOCK
-            TABLES</literal> with transactional tables, like
-            <literal>InnoDB</literal>, is to set <literal>AUTOCOMMIT =
-            0</literal> and not to call <literal>UNLOCK TABLES</literal>
-            until you commit the transaction explicitly. For example, if
-            you need to write to table <literal>t1</literal> and read
-            from table <literal>t2</literal>, you can do this:
+            TABLES</literal> with transactional tables, such as
+            <literal>InnoDB</literal> tables, is to set
+            <literal>AUTOCOMMIT = 0</literal> and not to call
+            <literal>UNLOCK TABLES</literal> until after you commit the
+            transaction explicitly. For example, if you need to write to
+            table <literal>t1</literal> and read from table
+            <literal>t2</literal>, you can do this:
           </para>
 
 <programlisting>
 SET AUTOCOMMIT=0;
 LOCK TABLES t1 WRITE, t2 READ, ...;
-[do something with tables t1 and t2 here];
+<replaceable>... do something with tables t1 and t2 here ...</replaceable>
 COMMIT;
 UNLOCK TABLES;
 </programlisting>
@@ -4527,7 +4530,7 @@
 
         <listitem>
           <para>
-            In applications using the <literal>LOCK TABLES</literal>
+            In applications that use the <literal>LOCK TABLES</literal>
             command, MySQL does not set <literal>InnoDB</literal> table
             locks if <literal>AUTOCOMMIT=1</literal>.
           </para>
@@ -4576,8 +4579,8 @@
       <listitem>
         <para>
           If you can afford the loss of some of the latest committed
-          transactions, you can set the <filename>my.cnf</filename>
-          parameter <literal>innodb_flush_log_at_trx_commit</literal> to
+          transactions if a crash occurs, you can set the
+          <literal>innodb_flush_log_at_trx_commit</literal> parameter to
           0. <literal>InnoDB</literal> tries to flush the log once per
           second anyway, although the flush is not guaranteed.
         </para>
@@ -4607,8 +4610,8 @@
           strings or if the column may contain many
           <literal>NULL</literal> values. A
           <literal>CHAR(<replaceable>N</replaceable>)</literal> column
-          always takes <replaceable>N</replaceable> bytes to store data,
-          even if the string is shorter or its value is
+          always takes <replaceable>N</replaceable> characters to store
+          data, even if the string is shorter or its value is
           <literal>NULL</literal>. Smaller tables fit better in the
           buffer pool and reduce disk I/O.
         </para>
@@ -4627,14 +4630,14 @@
       <listitem>
         <para>
           In some versions of GNU/Linux and Unix, flushing files to disk
-          with the Unix <literal>fsync()</literal> (which
+          with the Unix <literal>fsync()</literal> call (which
           <literal>InnoDB</literal> uses by default) and other similar
           methods is surprisingly slow. If you are dissatisfied with
-          database write performance, you might try setting
-          <literal>innodb_flush_method</literal> in
-          <filename>my.cnf</filename> to <literal>O_DSYNC</literal>,
-          although <literal>O_DSYNC</literal> seems to be slower on most
-          systems.
+          database write performance, you might try setting the
+          <literal>innodb_flush_method</literal> parameter to
+          <literal>O_DSYNC</literal>. Although
+          <literal>O_DSYNC</literal> seems to be slower on most systems,
+          yours might not be one of them.
         </para>
       </listitem>
 
@@ -4646,28 +4649,28 @@
           <literal>InnoDB</literal>-related files using the
           <literal>forcedirectio</literal> option. (The default on
           Solaris 10/x86_64 is <emphasis>not</emphasis> to use this
-          filesystem mounting option.) Failing to use
-          <literal>forcedirectio</literal> will cause a serious
-          degradation of <literal>InnoDB</literal>'s speed and
-          performance on this platform.
+          option.) Failure to use <literal>forcedirectio</literal>
+          causes a serious degradation of <literal>InnoDB</literal>'s
+          speed and performance on this platform.
         </para>
 
         <para>
           When using the <literal>InnoDB</literal> storage engine with a
           large <literal>innodb_buffer_pool_size</literal> value on any
-          release Solaris &ge; 2.6 and any platform
+          release of Solaris 2.6 and up and any platform
           (sparc/x86/x64/amd64), a significant performance gain can be
           achieved by placing <literal>InnoDB</literal> data files and
           log files on raw devices or on a separate direct I/O UFS
-          Filesystem (mount option <literal>forcedirectio</literal>; see
+          filesystem (using mount option
+          <literal>forcedirectio</literal>; see
           <literal>mount_ufs(1M)</literal>). Users of the Veritas
           filesystem VxFS should use the mount option
           <literal>convosync=direct</literal>.
         </para>
 
         <para>
-          Other MySQL data files such as those for
-          <literal>MyISAM</literal> tables should not be placed on a
+          Other MySQL data files, such as those for
+          <literal>MyISAM</literal> tables, should not be placed on a
           direct I/O filesystem. Executables or libraries <emphasis>must
           not</emphasis> be placed on a direct I/O filesystem.
         </para>
@@ -4677,7 +4680,7 @@
         <para>
           When importing data into <literal>InnoDB</literal>, make sure
           that MySQL does not have autocommit mode enabled because that
-          would require a log flush to disk for every insert. To disable
+          requires a log flush to disk for every insert. To disable
           autocommit during your import operation, surround it with
           <literal>SET AUTOCOMMIT</literal> and
           <literal>COMMIT</literal> statements:
@@ -4685,7 +4688,7 @@
 
 <programlisting>
 SET AUTOCOMMIT=0;
-/* SQL import statements ... */
+<replaceable>... SQL import statements ...</replaceable>
 COMMIT;
 </programlisting>
 
@@ -6906,11 +6909,11 @@
         <para>
           In MySQL &current-series;, the MySQL <literal>LOCK
           TABLES</literal> operation acquires two locks on each table if
-          <literal>innodb_table_locks=1</literal>, with 1 being the
-          default.) In addition to a table lock on the MySQL layer, it
-          also acquires an <literal>InnoDB</literal> table lock. Older
-          versions of MySQL did not acquire <literal>InnoDB</literal>
-          table locks; the old behavior can be selected by setting
+          <literal>innodb_table_locks=1</literal> (the default). In
+          addition to a table lock on the MySQL layer, it also acquires
+          an <literal>InnoDB</literal> table lock. Older versions of
+          MySQL did not acquire <literal>InnoDB</literal> table locks;
+          the old behavior can be selected by setting
           <literal>innodb_table_locks=0</literal>. If no
           <literal>InnoDB</literal> table lock is acquired,
           <literal>LOCK TABLES</literal> completes even if some records

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