List:Commits« Previous MessageNext Message »
From:paul Date:January 8 2006 1:30am
Subject:svn commit - mysqldoc@docsrva: r718 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-08 02:30:12 +0100 (Sun, 08 Jan 2006)
New Revision: 718

Log:
 r5950@frost:  paul | 2006-01-07 19:24:22 -0600
 Add tags.


Modified:
   trunk/
   trunk/refman-4.1/connector-j.xml
   trunk/refman-4.1/database-administration.xml
   trunk/refman-4.1/innodb.xml
   trunk/refman-4.1/installing.xml
   trunk/refman-4.1/ndbcluster.xml
   trunk/refman-4.1/replication.xml
   trunk/refman-4.1/sql-syntax.xml
   trunk/refman-4.1/tutorial.xml
   trunk/refman-5.0/apis.xml
   trunk/refman-5.0/connector-j.xml
   trunk/refman-5.0/database-administration.xml
   trunk/refman-5.0/innodb.xml
   trunk/refman-5.0/installing.xml
   trunk/refman-5.0/ndbcluster.xml
   trunk/refman-5.0/optimization.xml
   trunk/refman-5.0/replication.xml
   trunk/refman-5.0/sql-syntax.xml
   trunk/refman-5.1/apis.xml
   trunk/refman-5.1/connector-j.xml
   trunk/refman-5.1/custom-engine.xml
   trunk/refman-5.1/database-administration.xml
   trunk/refman-5.1/innodb.xml
   trunk/refman-5.1/installing.xml
   trunk/refman-5.1/ndbcluster.xml
   trunk/refman-5.1/optimization.xml
   trunk/refman-5.1/pluggable-storage.xml
   trunk/refman-5.1/replication.xml
   trunk/refman-5.1/sql-syntax.xml
   trunk/refman-5.1/storage-engines.xml


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

Modified: trunk/refman-4.1/connector-j.xml
===================================================================
--- trunk/refman-4.1/connector-j.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-4.1/connector-j.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -2742,7 +2742,7 @@
           <para>
             The earliest the locks these statements hold can be released
             (whether they be <literal>MyISAM</literal> table-level locks or row-level locks
-            in some other storage engine such as InnoDB) is when the
+            in some other storage engine such as <literal>InnoDB</literal>) is when the
             statement completes.
           </para>
 

Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-4.1/database-administration.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -9470,7 +9470,7 @@
         <para>
           Each storage engine performs any actions necessary for tables
           that it manages. For example, <literal>MyISAM</literal> flushes any pending index
-          writes for a table. InnoDB flushes its buffer pool to disk,
+          writes for a table. <literal>InnoDB</literal> flushes its buffer pool to disk,
           writes the current LSN to the tablespace, and terminates its
           own internal threads.
         </para>

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-4.1/innodb.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -270,7 +270,7 @@
       because of write operations having been reordered. If data
       integrity is important to you, you should perform some
       <quote>pull-the-plug</quote> tests before using anything in
-      production. On Mac OS X 10.3 and later, InnoDB uses a special
+      production. On Mac OS X 10.3 and later, <literal>InnoDB</literal> uses a special
       <literal>fcntl()</literal> file flush method. Under Linux, it is
       advisable to <emphasis role="bold">disable the write-back
       cache</emphasis>.
@@ -975,14 +975,14 @@
           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,
-          InnoDB's crash recovery is not affected and thus crash
+          <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 InnoDB database. Using 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
@@ -1056,7 +1056,7 @@
           transaction may wait for a lock before being rolled back.
           <literal>InnoDB</literal> automatically detects transaction
           deadlocks in its own lock table and rolls back the
-          transaction. Beginning with MySQL 4.0.20 and 4.1.2, InnoDB
+          transaction. Beginning with MySQL 4.0.20 and 4.1.2, <literal>InnoDB</literal>
           notices locks set using the <literal>LOCK TABLES</literal>
           statement. Before that, if you use the <literal>LOCK
           TABLES</literal> statement, or other transaction-safe storage
@@ -1115,9 +1115,9 @@
           same <literal>SELECT</literal> within the same transaction,
           you see a new row in the result set returned by the query.
           This also means, that if new items are added to the database,
-          InnoDB does not guarantee serializability instead conflict
+          <literal>InnoDB</literal> does not guarantee serializability instead conflict
           serializability is still guaranteed. Therefore, if this option
-          is used InnoDB guarantees at most isolation level
+          is used <literal>InnoDB</literal> guarantees at most isolation level
           <literal>READ COMMITTED</literal>. This option is available as
           of MySQL 4.1.4.
         </para>
@@ -1249,7 +1249,7 @@
         </para>
 
         <para>
-          The InnoDB transaction system maintains a list of transactions
+          The <literal>InnoDB</literal> transaction system maintains a list of transactions
           that have delete-marked index records by
           <literal>UPDATE</literal> or <literal>DELETE</literal>
           operations. Let the length of this list be
@@ -1350,9 +1350,9 @@
           <literal>InnoDB</literal> ignored table locks, which allowed one to more easily
           simulate transactions with a combination of <literal>MyISAM</literal> and <literal>InnoDB</literal>
           tables. The default value is 1, which means that <literal>LOCK
-          TABLES</literal> causes also InnoDB internally to take a table
+          TABLES</literal> causes also <literal>InnoDB</literal> internally to take a table
           lock. In applications using <literal>AUTOCOMMIT=1</literal>,
-          InnoDB's internal table locks can cause deadlocks. You can set
+          <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.
@@ -1501,7 +1501,7 @@
     <para>
       Starting from MySQL 4.1.1, you can add the option
       <literal>innodb_file_per_table</literal> to
-      <filename>my.cnf</filename>, and make InnoDB to store each table
+      <filename>my.cnf</filename>, and make <literal>InnoDB</literal> to store each table
       into its own <filename>.ibd</filename> file in a database
       directory of MySQL. See <xref linkend="multiple-tablespaces"/>.
     </para>
@@ -1520,7 +1520,7 @@
         <listitem>
           <para>
             You did not create the <literal>InnoDB</literal> data file
-            directory or the InnoDB log directory.
+            directory or the <literal>InnoDB</literal> log directory.
           </para>
         </listitem>
 
@@ -2160,13 +2160,13 @@
       <para>
         <emphasis role="bold">Deviation from SQL standards</emphasis>:
         Like MySQL in general, in an SQL statement that inserts,
-        deletes, or updates many rows, InnoDB checks
+        deletes, or updates many rows, <literal>InnoDB</literal> checks
         <literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
         constraints row-by-row. According to the SQL standard, the
         default behavior should be deferred checking, that is,
         constraints are only checked after the
         <emphasis role="bold">whole SQL statement</emphasis> has been
-        processed. Until InnoDB implements deferred constraint checking,
+        processed. Until <literal>InnoDB</literal> implements deferred constraint checking,
         some things will be impossible, such as deleting a record that
         refers to itself via a foreign key.
       </para>
@@ -2569,7 +2569,7 @@
         Using multiple tablespaces can be beneficial to users who want
         to move specific tables to separate physical disks or who wish
         to restore backups of single tables quickly without interrupting
-        the use of the remaining InnoDB tables.
+        the use of the remaining <literal>InnoDB</literal> tables.
       </para>
 
       <para>
@@ -4572,7 +4572,7 @@
           <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 InnoDB, is
+            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
@@ -4611,12 +4611,12 @@
         <listitem>
           <para>
             In applications using <literal>AUTOCOMMIT=1</literal> and
-            MySQL's <literal>LOCK TABLES</literal> command, InnoDB's
+            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 from 4.0.22, you can set
             <literal>innodb_table_locks=0</literal> in
             <filename>my.cnf</filename> to fall back to the old behavior
-            and remove the problem. 4.0.24 does not set InnoDB table
+            and remove the problem. 4.0.24 does not set <literal>InnoDB</literal> table
             locks if <literal>AUTOCOMMIT=1</literal>.
           </para>
         </listitem>
@@ -4722,14 +4722,14 @@
         <para>
           (Verified using MySQL 4.1, assumed for other MySQL versions,
           given that this is a platform architecture issue.) When using
-          the InnoDB storage engine on Solaris 10 for x86_64
+          the <literal>InnoDB</literal> storage engine on Solaris 10 for x86_64
           architecture (AMD Opteron), it is important to mount any
-          filesystems used for storing InnoDB-related files using the
+          filesystems used for storing <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 InnoDB's speed and performance on this
+          degradation of <literal>InnoDB</literal>'s speed and performance on this
           platform.
         </para>
 
@@ -5844,7 +5844,7 @@
       <para>
         A symptom of fragmentation is that a table takes more space than
         it <quote>should</quote> take. How much that is exactly, is
-        difficult to determine. All InnoDB data and indexes are stored
+        difficult to determine. All <literal>InnoDB</literal> data and indexes are stored
         in B-trees, and their fill factor may vary from 50% to 100%.
         Another symptom of fragmentation is that a table scan such as:
       </para>
@@ -7121,7 +7121,7 @@
           course of a transaction. Unfortunately, <literal>LOCK
           TABLES</literal> in MySQL performs an implicit
           <literal>COMMIT</literal> and <literal>UNLOCK
-          TABLES</literal>. An InnoDB variant of <literal>LOCK
+          TABLES</literal>. An <literal>InnoDB</literal> variant of <literal>LOCK
           TABLES</literal> has been planned that can be executed in the
           middle of a transaction.
         </para>
@@ -7316,7 +7316,7 @@
       <para>
         Older MySQL versions did not allow accessing any table with a
         name containing &lsquo;<literal>#</literal>&rsquo;. The solution
-        in older MySQL versions is to use a special InnoDB mechanism
+        in older MySQL versions is to use a special <literal>InnoDB</literal> mechanism
         available starting from MySQL 3.23.48. When you have an orphaned
         table <filename>#sql-id</filename> inside the tablespace, you
         can cause <literal>InnoDB</literal> to rename it to

Modified: trunk/refman-4.1/installing.xml
===================================================================
--- trunk/refman-4.1/installing.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-4.1/installing.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -12877,7 +12877,7 @@
           <para>
             A new startup option named
             <option>innodb_table_locks</option> was added that causes
-            <literal>LOCK TABLE</literal> to also acquire InnoDB table
+            <literal>LOCK TABLE</literal> to also acquire <literal>InnoDB</literal> table
             locks. This option is enabled by default. This can cause
             deadlocks in applications that use
             <literal>AUTOCOMMIT=1</literal> and <literal>LOCK
@@ -12892,7 +12892,7 @@
           <para>
             A new startup option named
             <option>innodb_table_locks</option> was added that causes
-            <literal>LOCK TABLE</literal> to also acquire InnoDB table
+            <literal>LOCK TABLE</literal> to also acquire <literal>InnoDB</literal> table
             locks. This option is enabled by default. This can cause
             deadlocks in applications that use
             <literal>AUTOCOMMIT=1</literal> and <literal>LOCK
@@ -15056,7 +15056,7 @@
 
       <para>
         When using Solaris 10 for x86_64, you should mount any
-        filesystems on which you intend to store InnoDB files with the
+        filesystems on which you intend to store <literal>InnoDB</literal> files with the
         <option>forcedirectio</option> option. (By default mounting is
         done without this option.) Failing to do so will cause a
         significant drop in performance when using the
@@ -17192,7 +17192,7 @@
           <command>configure</command> command needs to build both a
           static and a dynamic library in
           <filename><replaceable>src_directory</replaceable>/bdb/build_unix/</filename>,
-          but it does not with MySQL's own BDB version. The workaround
+          but it does not with MySQL's own <literal>BDB</literal> version. The workaround
           is as follows.
         </para>
 
@@ -17515,7 +17515,7 @@
           <command>configure</command> command needs to build both a
           static and a dynamic library in
           <filename><replaceable>src_directory</replaceable>/bdb/build_unix/</filename>,
-          but it does not with MySQL's own BDB version. The workaround
+          but it does not with MySQL's own <literal>BDB</literal> version. The workaround
           is as follows.
         </para>
 

Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-4.1/ndbcluster.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -8739,7 +8739,7 @@
     <para>
       In this section, we provide a listing of known limitations in
       MySQL Cluster releases in the &current-series;.x series when
-      compared to features available when using the <literal>MyISAM</literal> and InnoDB
+      compared to features available when using the <literal>MyISAM</literal> and <literal>InnoDB</literal>
       storage engines. Currently there are no plans to address these in
       coming releases of MySQL &current-series;; however, we will
       attempt to supply fixes for these issues in subsequent release
@@ -9240,7 +9240,7 @@
           slow transaction can cause the slave to lag behind the master.
           This means that if the master fails, it is possible that the
           slave might not have recorded the last few transactions. If a
-          transaction-safe engine such as InnoDB is being used, then a
+          transaction-safe engine such as <literal>InnoDB</literal> is being used, then a
           transaction will either be complete on the slave or not
           applied at all, but replication does not guarantee that all
           data on the master and the slave will be consistent at all

Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-4.1/replication.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -1070,7 +1070,7 @@
           <literal>InnoDB</literal> storage engine) the snapshot won't
           be consistent (because the <literal>InnoDB</literal> caches
           are not flushed), but there's no need to worry at all, because
-          InnoDB will resolve this at startup, and consequently deliver
+          <literal>InnoDB</literal> will resolve this at startup, and consequently deliver
           a consistent result. This means that <literal>InnoDB</literal>
           will perform a crash recovery when started on this snapshot,
           but it will not be corrupted. If you want to have a consistent
@@ -1835,7 +1835,7 @@
           <literal>slave_transaction_retries</literal>: If the
           replication slave SQL thread fails to execute a transaction
           because of an <literal>InnoDB</literal> deadlock or exceeded
-          InnoDB's <literal>innodb_lock_wait_timeout</literal> or
+          <literal>InnoDB</literal>'s <literal>innodb_lock_wait_timeout</literal> or
           NDBCluster's
           <literal>TransactionDeadlockDetectionTimeout</literal> or
           <literal>TransactionInactiveTimeout</literal>, it

Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-4.1/sql-syntax.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -12884,9 +12884,9 @@
             checks for secondary indexes in <literal>InnoDB</literal>
             tables are performed. If set to <literal>0</literal>,
             uniqueness checks are not done for index entries inserted
-            into InnoDB's insert buffer. If you know for certain that
+            into <literal>InnoDB</literal>'s insert buffer. If you know for certain that
             your data does not contain uniqueness violations, you can
-            set this to 0 to speed up large table imports to InnoDB.
+            set this to 0 to speed up large table imports to <literal>InnoDB</literal>.
             This variable was added in MySQL 3.23.52.
           </para>
         </listitem>
@@ -15166,7 +15166,7 @@
               The row storage format (<literal>Fixed</literal>,
               <literal>Dynamic</literal>, <literal>Compressed</literal>,
               <literal>Redundant</literal>, <literal>Compact</literal>).
-              InnoDB tables are always in the
+              <literal>InnoDB</literal> tables are always in the
               <literal>Redundant</literal> format.
             </para>
           </listitem>

Modified: trunk/refman-4.1/tutorial.xml
===================================================================
--- trunk/refman-4.1/tutorial.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-4.1/tutorial.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -3400,7 +3400,7 @@
       <remark role="todo">
         [js] This doesn't actually involve the creation of foreign keys
         at all. If anything, it's an example of a rather novel sort of
-        comment, and can't even be used with InnoDB tables. We should
+        comment, and can't even be used with <literal>InnoDB</literal> tables. We should
         either (a) rewrite the section to include a real example using
         real foreign keys or (b) rename the section - or perhaps remove
         it altogether. IMO, all this does now is provide fuel for "See?

Modified: trunk/refman-5.0/apis.xml
===================================================================
--- trunk/refman-5.0/apis.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/apis.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -359,8 +359,8 @@
 
         <listitem>
           <para>
-            We have to change InnoDB not to be so verbose when using the
-            embedded version. If your database does not contain InnoDB
+            We have to change <literal>InnoDB</literal> not to be so verbose when using the
+            embedded version. If your database does not contain <literal>InnoDB</literal>
             tables, to suppress related messages you can add the
             <option>--skip-innodb</option> option to the options file
             under the group <literal>[libmysqd_server]</literal>, or

Modified: trunk/refman-5.0/connector-j.xml
===================================================================
--- trunk/refman-5.0/connector-j.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/connector-j.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -2742,7 +2742,7 @@
           <para>
             The earliest the locks these statements hold can be released
             (whether they be <literal>MyISAM</literal> table-level locks or row-level locks
-            in some other storage engine such as InnoDB) is when the
+            in some other storage engine such as <literal>InnoDB</literal>) is when the
             statement completes.
           </para>
 

Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/database-administration.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -350,11 +350,11 @@
           </para>
 
           <para>
-            This option enables support for the InnoDB storage engine.
-            MySQL-Max servers always include InnoDB support. From MySQL
-            4.0 onward, InnoDB is included by default in all binary
+            This option enables support for the <literal>InnoDB</literal> storage engine.
+            MySQL-Max servers always include <literal>InnoDB</literal> support. From MySQL
+            4.0 onward, <literal>InnoDB</literal> is included by default in all binary
             distributions, so you do not need a MySQL-Max server merely
-            to obtain InnoDB support.
+            to obtain <literal>InnoDB</literal> support.
           </para>
         </listitem>
 
@@ -419,8 +419,8 @@
       </para>
 
       <para>
-        MySQL-Max servers include the BerkeleyDB (BDB) storage engine
-        whenever possible, but not all platforms support BDB.
+        MySQL-Max servers include the <literal>BerkeleyDB</literal> (<literal>BDB</literal>) storage engine
+        whenever possible, but not all platforms support <literal>BDB</literal>.
       </para>
 
       <para>
@@ -434,7 +434,7 @@
 
       <para>
         The following table shows on which platforms MySQL-Max binaries
-        include support for BDB and NDB Cluster:
+        include support for <literal>BDB</literal> and NDB Cluster:
       </para>
 
       <informaltable>
@@ -2408,7 +2408,7 @@
               shut down. The default is 35 seconds. After the delay
               expires, the IM assumes that the instance is hanging and
               attempts to <literal>kill -9</literal> it. If you use
-              InnoDB with large tables, you should increase this value.
+              <literal>InnoDB</literal> with large tables, you should increase this value.
             </para>
           </listitem>
 
@@ -8400,7 +8400,7 @@
             <para>
               If a replication slave SQL thread fails to execute a
               transaction because of an <literal>InnoDB</literal>
-              deadlock or exceeded InnoDB's
+              deadlock or exceeded <literal>InnoDB</literal>'s
               <literal>innodb_lock_wait_timeout</literal> or
               NDBCluster's
               <literal>TransactionDeadlockDetectionTimeout</literal> or
@@ -11431,7 +11431,7 @@
         <para>
           Each storage engine performs any actions necessary for tables
           that it manages. For example, <literal>MyISAM</literal> flushes any pending index
-          writes for a table. InnoDB flushes its buffer pool to disk
+          writes for a table. <literal>InnoDB</literal> flushes its buffer pool to disk
           (starting from 5.0.5: unless
           <literal>innodb_fast_shutdown</literal> is 2), writes the
           current LSN to the tablespace, and terminates its own internal

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/innodb.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -195,7 +195,7 @@
       because of write operations having been reordered. If data
       integrity is important to you, you should perform some
       <quote>pull-the-plug</quote> tests before using anything in
-      production. On Mac OS X 10.3 and later, InnoDB uses a special
+      production. On Mac OS X 10.3 and later, <literal>InnoDB</literal> uses a special
       <literal>fcntl()</literal> file flush method. Under Linux, it is
       advisable to <emphasis role="bold">disable the write-back
       cache</emphasis>.
@@ -881,7 +881,7 @@
           If you set this parameter to 1, <literal>InnoDB</literal>
           skips these operations at shutdown. The default value is 1. If
           you set it to 2 (available starting from MySQL 5.0.5, except
-          on Netware), InnoDB will just flush its logs and then shut
+          on Netware), <literal>InnoDB</literal> will just flush its logs and then shut
           down cold, as if MySQL had crashed; no committed transaction
           will be lost, but a crash recovery will be done at next
           startup.
@@ -961,14 +961,14 @@
           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,
-          InnoDB's crash recovery is not affected and thus crash
+          <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 InnoDB database. Using 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
@@ -1029,7 +1029,7 @@
           transaction may wait for a lock before being rolled back.
           <literal>InnoDB</literal> automatically detects transaction
           deadlocks in its own lock table and rolls back the
-          transaction. InnoDB notices locks set using the <literal>LOCK
+          transaction. <literal>InnoDB</literal> notices locks set using the <literal>LOCK
           TABLES</literal> statement. The default is 50 seconds.
         </para>
 
@@ -1092,9 +1092,9 @@
           you execute the same <literal>SELECT</literal> within the same
           transaction, you see a new row in the result set returned by
           the query. This also means, that if new items are added to the
-          database, InnoDB does not guarantee serializability; however,
+          database, <literal>InnoDB</literal> does not guarantee serializability; however,
           conflict serializability is still guaranteed. Therefore, if
-          this option is used InnoDB guarantees at most isolation level
+          this option is used <literal>InnoDB</literal> guarantees at most isolation level
           <literal>READ COMMITTED</literal>.
         </para>
 
@@ -1297,7 +1297,7 @@
         </para>
 
         <para>
-          The InnoDB transaction system maintains a list of transactions
+          The <literal>InnoDB</literal> transaction system maintains a list of transactions
           that have delete-marked index records by
           <literal>UPDATE</literal> or <literal>DELETE</literal>
           operations. Let the length of this list be
@@ -1421,9 +1421,9 @@
           TABLES</literal>; MySQL does not return from <literal>LOCK
           TABLE .. WRITE</literal> until all other threads have released
           all their locks to the table. The default value is 1, which
-          means that <literal>LOCK TABLES</literal> causes InnoDB to
+          means that <literal>LOCK TABLES</literal> causes <literal>InnoDB</literal> to
           lock a table internally. In applications using
-          <literal>AUTOCOMMIT=1</literal>, InnoDB's internal table locks
+          <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
@@ -1565,7 +1565,7 @@
 
     <para>
       You can add the option <literal>innodb_file_per_table</literal> to
-      <filename>my.cnf</filename>, and make InnoDB to store each table
+      <filename>my.cnf</filename>, and make <literal>InnoDB</literal> to store each table
       into its own <filename>.ibd</filename> file in a database
       directory of MySQL. See <xref linkend="multiple-tablespaces"/>.
     </para>
@@ -1584,7 +1584,7 @@
         <listitem>
           <para>
             You did not create the <literal>InnoDB</literal> data file
-            directory or the InnoDB log directory.
+            directory or the <literal>InnoDB</literal> log directory.
           </para>
         </listitem>
 
@@ -2213,12 +2213,12 @@
       <para>
         <emphasis role="bold">Deviation from SQL standards</emphasis>:
         Like MySQL in general, in an SQL statement that inserts,
-        deletes, or updates many rows, InnoDB checks
+        deletes, or updates many rows, <literal>InnoDB</literal> checks
         <literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
         constraints row-by-row. According to the SQL standard, the
         default behavior should be deferred checking, that is,
         constraints are only checked after the <emphasis>entire SQL
-        statement</emphasis> has been processed. Until InnoDB implements
+        statement</emphasis> has been processed. Until <literal>InnoDB</literal> implements
         deferred constraint checking, some things will be impossible,
         such as deleting a record that refers to itself via a foreign
         key.
@@ -2569,7 +2569,7 @@
         Using multiple tablespaces can be beneficial to users who want
         to move specific tables to separate physical disks or who wish
         to restore backups of single tables quickly without interrupting
-        the use of the remaining InnoDB tables.
+        the use of the remaining <literal>InnoDB</literal> tables.
       </para>
 
       <para>
@@ -4531,7 +4531,7 @@
           <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 InnoDB, is
+            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
@@ -4570,7 +4570,7 @@
         <listitem>
           <para>
             In applications using the <literal>LOCK TABLES</literal>
-            command, MySQL does not set InnoDB table locks if
+            command, MySQL does not set <literal>InnoDB</literal> table locks if
             <literal>AUTOCOMMIT=1</literal>.
           </para>
         </listitem>
@@ -4657,7 +4657,7 @@
 
         <para>
           When using <literal>row_format=compact</literal> (the default
-          InnoDB record format in MySQL &current-series;) and
+          <literal>InnoDB</literal> record format in MySQL &current-series;) and
           variable-length character sets, such as
           <literal>utf8</literal> or <literal>sjis</literal>,
           <literal>CHAR(<replaceable>N</replaceable>)</literal> will
@@ -4682,14 +4682,14 @@
 
       <listitem>
         <para>
-          When using the InnoDB storage engine on Solaris 10 for x86_64
+          When using the <literal>InnoDB</literal> storage engine on Solaris 10 for x86_64
           architecture (AMD Opteron), it is important to mount any
-          filesystems used for storing InnoDB-related files using the
+          filesystems used for storing <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 InnoDB's speed and performance on this
+          degradation of <literal>InnoDB</literal>'s speed and performance on this
           platform.
         </para>
 
@@ -5794,7 +5794,7 @@
       <para>
         A symptom of fragmentation is that a table takes more space than
         it <quote>should</quote> take. How much that is exactly, is
-        difficult to determine. All InnoDB data and indexes are stored
+        difficult to determine. All <literal>InnoDB</literal> data and indexes are stored
         in B-trees, and their fill factor may vary from 50% to 100%.
         Another symptom of fragmentation is that a table scan such as:
       </para>
@@ -7063,7 +7063,7 @@
           course of a transaction. Unfortunately, <literal>LOCK
           TABLES</literal> in MySQL performs an implicit
           <literal>COMMIT</literal> and <literal>UNLOCK
-          TABLES</literal>. An InnoDB variant of <literal>LOCK
+          TABLES</literal>. An <literal>InnoDB</literal> variant of <literal>LOCK
           TABLES</literal> has been planned that can be executed in the
           middle of a transaction.
         </para>
@@ -7168,7 +7168,7 @@
         <filename>.frm</filename> files around, or if the server crashes
         in the middle of a data dictionary operation, the
         <filename>.frm</filename> files may end up out of sync with
-        InnoDB's internal data dictionary.
+        <literal>InnoDB</literal>'s internal data dictionary.
       </para>
 
       <para>

Modified: trunk/refman-5.0/installing.xml
===================================================================
--- trunk/refman-5.0/installing.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/installing.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -12560,7 +12560,7 @@
           <para>
             A new startup option named
             <option>innodb_table_locks</option> was added that causes
-            <literal>LOCK TABLE</literal> to also acquire InnoDB table
+            <literal>LOCK TABLE</literal> to also acquire <literal>InnoDB</literal> table
             locks. This option is enabled by default. This can cause
             deadlocks in applications that use
             <literal>AUTOCOMMIT=1</literal> and <literal>LOCK
@@ -12575,7 +12575,7 @@
           <para>
             A new startup option named
             <option>innodb_table_locks</option> was added that causes
-            <literal>LOCK TABLE</literal> to also acquire InnoDB table
+            <literal>LOCK TABLE</literal> to also acquire <literal>InnoDB</literal> table
             locks. This option is enabled by default. This can cause
             deadlocks in applications that use
             <literal>AUTOCOMMIT=1</literal> and <literal>LOCK
@@ -14226,10 +14226,10 @@
 
       <para>
         When using Solaris 10 for x86_64, you should mount any
-        filesystems on which you intend to store InnoDB files with the
+        filesystems on which you intend to store <literal>InnoDB</literal> files with the
         <literal>forcedirectio</literal> option. (By default mounting is
         done without this option.) Failing to do so will cause a
-        significant drop in performance when using the InnoDB storage
+        significant drop in performance when using the <literal>InnoDB</literal> storage
         engine on this platform.
       </para>
 
@@ -16357,7 +16357,7 @@
           <command>configure</command> command needs to build both a
           static and a dynamic library in
           <filename><replaceable>src_directory</replaceable>/bdb/build_unix/</filename>,
-          but it does not with MySQL's own BDB version. The workaround
+          but it does not with MySQL's own <literal>BDB</literal> version. The workaround
           is as follows.
         </para>
 
@@ -16675,7 +16675,7 @@
           <command>configure</command> command needs to build both a
           static and a dynamic library in
           <filename><replaceable>src_directory</replaceable>/bdb/build_unix/</filename>,
-          but it does not with MySQL's own BDB version. The workaround
+          but it does not with MySQL's own <literal>BDB</literal> version. The workaround
           is as follows.
         </para>
 

Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/ndbcluster.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -8720,7 +8720,7 @@
     <para>
       In this section, we provide a listing of known limitations in
       MySQL Cluster releases in the &current-series;.x series when
-      compared to features available when using the <literal>MyISAM</literal> and InnoDB
+      compared to features available when using the <literal>MyISAM</literal> and <literal>InnoDB</literal>
       storage engines. Currently there are no plans to address these in
       coming releases of MySQL &current-series;; however, we will
       attempt to supply fixes for these issues in subsequent release
@@ -9517,7 +9517,7 @@
           slow transaction can cause the slave to lag behind the master.
           This means that if the master fails, it is possible that the
           slave might not have recorded the last few transactions. If a
-          transaction-safe engine such as InnoDB is being used, then a
+          transaction-safe engine such as <literal>InnoDB</literal> is being used, then a
           transaction will either be complete on the slave or not
           applied at all, but replication does not guarantee that all
           data on the master and the slave will be consistent at all

Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/optimization.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -6688,7 +6688,7 @@
           <para>
             Starting with MySQL/InnoDB 5.0.3, <literal>InnoDB</literal>
             tables use a more compact storage format. In earlier
-            versions of MySQL, InnoDB records contain some redundant
+            versions of MySQL, <literal>InnoDB</literal> records contain some redundant
             information, such as the number of columns and the length of
             each column, even for fixed-size columns. By default, tables
             are created in the compact format
@@ -6698,7 +6698,7 @@
           </para>
 
           <para>
-            The compact InnoDB format also changes the way how
+            The compact <literal>InnoDB</literal> format also changes the way how
             <literal>CHAR</literal> columns containing UTF-8 data are
             stored. In the <literal>ROW_FORMAT=REDUNDANT</literal>
             format, a UTF-8

Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/replication.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -1756,7 +1756,7 @@
           <literal>slave_transaction_retries</literal>: If the
           replication slave SQL thread fails to execute a transaction
           because of an <literal>InnoDB</literal> deadlock or exceeded
-          InnoDB's <literal>innodb_lock_wait_timeout</literal> or
+          <literal>InnoDB</literal>'s <literal>innodb_lock_wait_timeout</literal> or
           NDBCluster's
           <literal>TransactionDeadlockDetectionTimeout</literal> or
           <literal>TransactionInactiveTimeout</literal>, it

Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.0/sql-syntax.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -14164,9 +14164,9 @@
             checks for secondary indexes in <literal>InnoDB</literal>
             tables are performed. If set to <literal>0</literal>,
             uniqueness checks are not done for index entries inserted
-            into InnoDB's insert buffer. If you know for certain that
+            into <literal>InnoDB</literal>'s insert buffer. If you know for certain that
             your data does not contain uniqueness violations, you can
-            set this to 0 to speed up large table imports to InnoDB.
+            set this to 0 to speed up large table imports to <literal>InnoDB</literal>.
           </para>
         </listitem>
 
@@ -16500,7 +16500,7 @@
               Starting with MySQL/InnoDB 5.0.3, the format of
               <literal>InnoDB</literal> tables is reported as
               <literal>Redundant</literal> or
-              <literal>Compact</literal>. Prior to 5.0.3, InnoDB tables
+              <literal>Compact</literal>. Prior to 5.0.3, <literal>InnoDB</literal> tables
               are always in the <literal>Redundant</literal> format.
             </para>
           </listitem>

Modified: trunk/refman-5.1/apis.xml
===================================================================
--- trunk/refman-5.1/apis.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/apis.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -359,8 +359,8 @@
 
         <listitem>
           <para>
-            We have to change InnoDB not to be so verbose when using the
-            embedded version. If your database does not contain InnoDB
+            We have to change <literal>InnoDB</literal> not to be so verbose when using the
+            embedded version. If your database does not contain <literal>InnoDB</literal>
             tables, to suppress related messages you can add the
             <option>--skip-innodb</option> option to the options file
             under the group <literal>[libmysqd_server]</literal>, or

Modified: trunk/refman-5.1/connector-j.xml
===================================================================
--- trunk/refman-5.1/connector-j.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/connector-j.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -2742,7 +2742,7 @@
           <para>
             The earliest the locks these statements hold can be released
             (whether they be <literal>MyISAM</literal> table-level locks or row-level locks
-            in some other storage engine such as InnoDB) is when the
+            in some other storage engine such as <literal>InnoDB</literal>) is when the
             statement completes.
           </para>
 

Modified: trunk/refman-5.1/custom-engine.xml
===================================================================
--- trunk/refman-5.1/custom-engine.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/custom-engine.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -7169,7 +7169,7 @@
       </para>
 
       <para>
-        gets foreign key create string from InnoDB
+        gets foreign key create string from <literal>InnoDB</literal>
       </para>
 
       <bridgehead>Parameters</bridgehead>
@@ -8729,7 +8729,7 @@
 
       <para>
         The methods ha_retrieve_all_cols and ha_retrieve_all_pk are made
-        virtual to handle InnoDB specifics. If InnoDB doesn't need the
+        virtual to handle <literal>InnoDB</literal> specifics. If <literal>InnoDB</literal> doesn't need the
         extra parameters HA_EXTRA_RETRIEVE_ALL_COLS and
         HA_EXTRA_RETRIEVE_PRIMARY_KEY anymore then these methods need
         not be virtual anymore.
@@ -10671,7 +10671,7 @@
       <bridgehead>Purpose</bridgehead>
 
       <para>
-        prepare InnoDB for HANDLER
+        prepare <literal>InnoDB</literal> for <literal>HANDLER</literal>
       </para>
 
       <bridgehead>Synopsis</bridgehead>
@@ -12342,7 +12342,7 @@
         is the size needed to store current_position. ref is just a byte
         array that the server will maintain. If you are using offsets to
         mark rows, then current_position should be the offset. If it is
-        a primary key like in BDB, then it needs to be a primary key.
+        a primary key like in <literal>BDB</literal>, then it needs to be a primary key.
       </para>
 
       <para>
@@ -12658,7 +12658,7 @@
       </para>
 
       <para>
-        This is never called for InnoDB or BDB tables, as these table
+        This is never called for <literal>InnoDB</literal> or <literal>BDB</literal> tables, as these table
         types has the HA_NOT_EXACT_COUNT set.
       </para>
 

Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/database-administration.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -350,11 +350,11 @@
           </para>
 
           <para>
-            This option enables support for the InnoDB storage engine.
-            MySQL-Max servers always include InnoDB support. From MySQL
-            4.0 onward, InnoDB is included by default in all binary
+            This option enables support for the <literal>InnoDB</literal> storage engine.
+            MySQL-Max servers always include <literal>InnoDB</literal> support. From MySQL
+            4.0 onward, <literal>InnoDB</literal> is included by default in all binary
             distributions, so you do not need a MySQL-Max server merely
-            to obtain InnoDB support.
+            to obtain <literal>InnoDB</literal> support.
           </para>
         </listitem>
 
@@ -419,8 +419,8 @@
       </para>
 
       <para>
-        MySQL-Max servers include the BerkeleyDB (BDB) storage engine
-        whenever possible, but not all platforms support BDB.
+        MySQL-Max servers include the <literal>BerkeleyDB</literal> (<literal>BDB</literal>) storage engine
+        whenever possible, but not all platforms support <literal>BDB</literal>.
       </para>
 
       <para>
@@ -434,7 +434,7 @@
 
       <para>
         The following table shows on which platforms MySQL-Max binaries
-        include support for BDB and NDB Cluster:
+        include support for <literal>BDB</literal> and NDB Cluster:
       </para>
 
       <informaltable>
@@ -2392,7 +2392,7 @@
               shut down. The default is 35 seconds. After the delay
               expires, the IM assumes that the instance is hanging and
               attempts to <literal>kill -9</literal> it. If you use
-              InnoDB with large tables, you should increase this value.
+              <literal>InnoDB</literal> with large tables, you should increase this value.
             </para>
           </listitem>
 
@@ -8371,7 +8371,7 @@
             <para>
               If a replication slave SQL thread fails to execute a
               transaction because of an <literal>InnoDB</literal>
-              deadlock or exceeded InnoDB's
+              deadlock or exceeded <literal>InnoDB</literal>'s
               <literal>innodb_lock_wait_timeout</literal> or
               NDBCluster's
               <literal>TransactionDeadlockDetectionTimeout</literal> or
@@ -11408,7 +11408,7 @@
         <para>
           Each storage engine performs any actions necessary for tables
           that it manages. For example, <literal>MyISAM</literal> flushes any pending index
-          writes for a table. InnoDB flushes its buffer pool to disk
+          writes for a table. <literal>InnoDB</literal> flushes its buffer pool to disk
           unless <literal>innodb_fast_shutdown</literal> is 2), writes
           the current LSN to the tablespace, and terminates its own
           internal threads.

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/innodb.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -195,7 +195,7 @@
       because of write operations having been reordered. If data
       integrity is important to you, you should perform some
       <quote>pull-the-plug</quote> tests before using anything in
-      production. On Mac OS X 10.3 and later, InnoDB uses a special
+      production. On Mac OS X 10.3 and later, <literal>InnoDB</literal> uses a special
       <literal>fcntl()</literal> file flush method. Under Linux, it is
       advisable to <emphasis role="bold">disable the write-back
       cache</emphasis>.
@@ -877,7 +877,7 @@
           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. If
-          you set it to 2 (not available on Netware), InnoDB will just
+          you set it to 2 (not available on Netware), <literal>InnoDB</literal> will just
           flush its logs and then shut down cold, as if MySQL had
           crashed; no committed transaction will be lost, but a crash
           recovery will be done at next startup.
@@ -957,14 +957,14 @@
           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,
-          InnoDB's crash recovery is not affected and thus crash
+          <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 InnoDB database. Using 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
@@ -1025,7 +1025,7 @@
           transaction may wait for a lock before being rolled back.
           <literal>InnoDB</literal> automatically detects transaction
           deadlocks in its own lock table and rolls back the
-          transaction. InnoDB notices locks set using the <literal>LOCK
+          transaction. <literal>InnoDB</literal> notices locks set using the <literal>LOCK
           TABLES</literal> statement. The default is 50 seconds.
         </para>
 
@@ -1085,9 +1085,9 @@
           you execute the same <literal>SELECT</literal> within the same
           transaction, you see a new row in the result set returned by
           the query. This also means, that if new items are added to the
-          database, InnoDB does not guarantee serializability; however,
+          database, <literal>InnoDB</literal> does not guarantee serializability; however,
           conflict serializability is still guaranteed. Therefore, if
-          this option is used InnoDB guarantees at most isolation level
+          this option is used <literal>InnoDB</literal> guarantees at most isolation level
           <literal>READ COMMITTED</literal>.
         </para>
 
@@ -1289,7 +1289,7 @@
         </para>
 
         <para>
-          The InnoDB transaction system maintains a list of transactions
+          The <literal>InnoDB</literal> transaction system maintains a list of transactions
           that have delete-marked index records by
           <literal>UPDATE</literal> or <literal>DELETE</literal>
           operations. Let the length of this list be
@@ -1398,9 +1398,9 @@
           TABLES</literal>; MySQL does not return from <literal>LOCK
           TABLE .. WRITE</literal> until all other threads have released
           all their locks to the table. The default value is 1, which
-          means that <literal>LOCK TABLES</literal> causes InnoDB to
+          means that <literal>LOCK TABLES</literal> causes <literal>InnoDB</literal> to
           lock a table internally. In applications using
-          <literal>AUTOCOMMIT=1</literal>, InnoDB's internal table locks
+          <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
@@ -1541,7 +1541,7 @@
 
     <para>
       You can add the option <literal>innodb_file_per_table</literal> to
-      <filename>my.cnf</filename>, and make InnoDB to store each table
+      <filename>my.cnf</filename>, and make <literal>InnoDB</literal> to store each table
       into its own <filename>.ibd</filename> file in a database
       directory of MySQL. See <xref linkend="multiple-tablespaces"/>.
     </para>
@@ -1560,7 +1560,7 @@
         <listitem>
           <para>
             You did not create the <literal>InnoDB</literal> data file
-            directory or the InnoDB log directory.
+            directory or the <literal>InnoDB</literal> log directory.
           </para>
         </listitem>
 
@@ -2188,12 +2188,12 @@
       <para>
         <emphasis role="bold">Deviation from SQL standards</emphasis>:
         Like MySQL in general, in an SQL statement that inserts,
-        deletes, or updates many rows, InnoDB checks
+        deletes, or updates many rows, <literal>InnoDB</literal> checks
         <literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
         constraints row-by-row. According to the SQL standard, the
         default behavior should be deferred checking, that is,
         constraints are only checked after the <emphasis>entire SQL
-        statement</emphasis> has been processed. Until InnoDB implements
+        statement</emphasis> has been processed. Until <literal>InnoDB</literal> implements
         deferred constraint checking, some things will be impossible,
         such as deleting a record that refers to itself via a foreign
         key.
@@ -2544,7 +2544,7 @@
         Using multiple tablespaces can be beneficial to users who want
         to move specific tables to separate physical disks or who wish
         to restore backups of single tables quickly without interrupting
-        the use of the remaining InnoDB tables.
+        the use of the remaining <literal>InnoDB</literal> tables.
       </para>
 
       <para>
@@ -4259,7 +4259,7 @@
             <literal>innodb_table_locks=1</literal> 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
+            Otherwise, <literal>InnoDB</literal>'s automatic deadlock detection cannot
             detect deadlocks where such table locks are involved. Also,
             since the higher MySQL layer does not know about row-level
             locks, it is possible to get a table lock on a table where
@@ -4491,7 +4491,7 @@
           <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 InnoDB, is
+            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
@@ -4530,7 +4530,7 @@
         <listitem>
           <para>
             In applications using the <literal>LOCK TABLES</literal>
-            command, MySQL does not set InnoDB table locks if
+            command, MySQL does not set <literal>InnoDB</literal> table locks if
             <literal>AUTOCOMMIT=1</literal>.
           </para>
         </listitem>
@@ -4617,7 +4617,7 @@
 
         <para>
           When using <literal>row_format=compact</literal> (the default
-          InnoDB record format in MySQL &current-series;) and
+          <literal>InnoDB</literal> record format in MySQL &current-series;) and
           variable-length character sets, such as
           <literal>utf8</literal> or <literal>sjis</literal>,
           <literal>CHAR(<replaceable>N</replaceable>)</literal> will
@@ -4642,14 +4642,14 @@
 
       <listitem>
         <para>
-          When using the InnoDB storage engine on Solaris 10 for x86_64
+          When using the <literal>InnoDB</literal> storage engine on Solaris 10 for x86_64
           architecture (AMD Opteron), it is important to mount any
-          filesystems used for storing InnoDB-related files using the
+          filesystems used for storing <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 InnoDB's speed and performance on this
+          degradation of <literal>InnoDB</literal>'s speed and performance on this
           platform.
         </para>
 
@@ -5754,7 +5754,7 @@
       <para>
         A symptom of fragmentation is that a table takes more space than
         it <quote>should</quote> take. How much that is exactly, is
-        difficult to determine. All InnoDB data and indexes are stored
+        difficult to determine. All <literal>InnoDB</literal> data and indexes are stored
         in B-trees, and their fill factor may vary from 50% to 100%.
         Another symptom of fragmentation is that a table scan such as:
       </para>
@@ -7001,7 +7001,7 @@
           course of a transaction. Unfortunately, <literal>LOCK
           TABLES</literal> in MySQL performs an implicit
           <literal>COMMIT</literal> and <literal>UNLOCK
-          TABLES</literal>. An InnoDB variant of <literal>LOCK
+          TABLES</literal>. An <literal>InnoDB</literal> variant of <literal>LOCK
           TABLES</literal> has been planned that can be executed in the
           middle of a transaction.
         </para>
@@ -7106,7 +7106,7 @@
         <filename>.frm</filename> files around, or if the server crashes
         in the middle of a data dictionary operation, the
         <filename>.frm</filename> files may end up out of sync with
-        InnoDB's internal data dictionary.
+        <literal>InnoDB</literal>'s internal data dictionary.
       </para>
 
       <para>

Modified: trunk/refman-5.1/installing.xml
===================================================================
--- trunk/refman-5.1/installing.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/installing.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -13538,10 +13538,10 @@
 
       <para>
         When using Solaris 10 for x86_64, you should mount any
-        filesystems on which you intend to store InnoDB files with the
+        filesystems on which you intend to store <literal>InnoDB</literal> files with the
         <literal>forcedirectio</literal> option. (By default mounting is
         done without this option.) Failing to do so will cause a
-        significant drop in performance when using the InnoDB storage
+        significant drop in performance when using the <literal>InnoDB</literal> storage
         engine on this platform.
       </para>
 
@@ -15669,7 +15669,7 @@
           <command>configure</command> command needs to build both a
           static and a dynamic library in
           <filename><replaceable>src_directory</replaceable>/bdb/build_unix/</filename>,
-          but it does not with MySQL's own BDB version. The workaround
+          but it does not with MySQL's own <literal>BDB</literal> version. The workaround
           is as follows.
         </para>
 
@@ -15987,7 +15987,7 @@
           <command>configure</command> command needs to build both a
           static and a dynamic library in
           <filename><replaceable>src_directory</replaceable>/bdb/build_unix/</filename>,
-          but it does not with MySQL's own BDB version. The workaround
+          but it does not with MySQL's own <literal>BDB</literal> version. The workaround
           is as follows.
         </para>
 

Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/ndbcluster.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -10332,7 +10332,7 @@
     <para>
       In this section, we provide a listing of known limitations in
       MySQL Cluster releases in the &current-series;.x series when
-      compared to features available when using the <literal>MyISAM</literal> and InnoDB
+      compared to features available when using the <literal>MyISAM</literal> and <literal>InnoDB</literal>
       storage engines. Currently there are no plans to address these in
       coming releases of MySQL &current-series;; however, we will
       attempt to supply fixes for these issues in subsequent release
@@ -11097,7 +11097,7 @@
           slow transaction can cause the slave to lag behind the master.
           This means that if the master fails, it is possible that the
           slave might not have recorded the last few transactions. If a
-          transaction-safe engine such as InnoDB is being used, then a
+          transaction-safe engine such as <literal>InnoDB</literal> is being used, then a
           transaction will either be complete on the slave or not
           applied at all, but replication does not guarantee that all
           data on the master and the slave will be consistent at all

Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/optimization.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -6657,7 +6657,7 @@
         <listitem>
           <para>
             In MySQL/InnoDB, <literal>InnoDB</literal> tables use a more
-            compact storage format. In earlier versions of MySQL, InnoDB
+            compact storage format. In earlier versions of MySQL, <literal>InnoDB</literal>
             records contain some redundant information, such as the
             number of columns and the length of each column, even for
             fixed-size columns. By default, tables are created in the
@@ -6668,7 +6668,7 @@
           </para>
 
           <para>
-            The compact InnoDB format also changes the way how
+            The compact <literal>InnoDB</literal> format also changes the way how
             <literal>CHAR</literal> columns containing UTF-8 data are
             stored. In the <literal>ROW_FORMAT=REDUNDANT</literal>
             format, a UTF-8

Modified: trunk/refman-5.1/pluggable-storage.xml
===================================================================
--- trunk/refman-5.1/pluggable-storage.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/pluggable-storage.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -270,7 +270,7 @@
       <listitem>
         <para>
           <literal>BDB</literal> - an alternative transaction engine to
-          InnoDB that supports COMMIT, ROLLBACK, and other transactional
+          <literal>InnoDB</literal> that supports <literal>COMMIT</literal>, <literal>ROLLBACK</literal>, and other transactional
           features.
         </para>
       </listitem>

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/replication.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -1956,7 +1956,7 @@
           <literal>slave_transaction_retries</literal>: If the
           replication slave SQL thread fails to execute a transaction
           because of an <literal>InnoDB</literal> deadlock or exceeded
-          InnoDB's <literal>innodb_lock_wait_timeout</literal> or
+          <literal>InnoDB</literal>'s <literal>innodb_lock_wait_timeout</literal> or
           NDBCluster's
           <literal>TransactionDeadlockDetectionTimeout</literal> or
           <literal>TransactionInactiveTimeout</literal>, it
@@ -4354,7 +4354,7 @@
 
         <listitem>
           <para>
-            For InnoDB: An <literal>INSERT</literal> statement that uses
+            For <literal>InnoDB</literal>: An <literal>INSERT</literal> statement that uses
             <literal>auto_increment</literal> will block other
             non-conflicting <literal>INSERT</literal> statements.
           </para>

Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/sql-syntax.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -14642,9 +14642,9 @@
             checks for secondary indexes in <literal>InnoDB</literal>
             tables are performed. If set to <literal>0</literal>,
             uniqueness checks are not done for index entries inserted
-            into InnoDB's insert buffer. If you know for certain that
+            into <literal>InnoDB</literal>'s insert buffer. If you know for certain that
             your data does not contain uniqueness violations, you can
-            set this to 0 to speed up large table imports to InnoDB.
+            set this to 0 to speed up large table imports to <literal>InnoDB</literal>.
           </para>
         </listitem>
 

Modified: trunk/refman-5.1/storage-engines.xml
===================================================================
--- trunk/refman-5.1/storage-engines.xml	2006-01-08 01:29:03 UTC (rev 717)
+++ trunk/refman-5.1/storage-engines.xml	2006-01-08 01:30:12 UTC (rev 718)
@@ -2629,7 +2629,7 @@
           </para>
 
           <para>
-            Turn off system buffering of BDB database files to avoid
+            Turn off system buffering of <literal>BDB</literal> database files to avoid
             double caching. This option was added in MySQL 5.1.4.
           </para>
         </listitem>
@@ -2667,7 +2667,7 @@
           </para>
 
           <para>
-            Turn off system buffering of BDB log files to avoid double
+            Turn off system buffering of <literal>BDB</literal> log files to avoid double
             caching. This option was added in MySQL 5.1.4.
           </para>
         </listitem>

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