List:Commits« Previous MessageNext Message »
From:jon.stephens Date:April 7 2011 8:19am
Subject:svn commit - mysqldoc@oter02: r25775 - trunk/innodb-plugin-1.0
View as plain text  
Author: js221926
Date: 2011-04-07 10:19:29 +0200 (Thu, 07 Apr 2011)
New Revision: 25775

Log:

Replace undefined entity refs that were breaking the build



Modified:
   trunk/innodb-plugin-1.0/innodb-information-schema.xml


Modified: trunk/innodb-plugin-1.0/innodb-information-schema.xml
===================================================================
--- trunk/innodb-plugin-1.0/innodb-information-schema.xml	2011-04-06 22:35:01 UTC (rev 25774)
+++ trunk/innodb-plugin-1.0/innodb-information-schema.xml	2011-04-07 08:19:29 UTC (rev 25775)
Changed blocks: 5, Lines Added: 29, Lines Deleted: 27; 5142 bytes

@@ -7,11 +7,11 @@
 ]>
 <chapter id="innodb-information-schema">
 
-  <title>&innodb; &INFORMATION_SCHEMA; Tables</title>
+  <title>&innodb; <literal>INFORMATION_SCHEMA</literal> Tables</title>
 
   <section id="innodb-information-schema-overview">
 
-    <title>Overview of InnoDB Support in &INFORMATION_SCHEMA;</title>
+    <title>Overview of InnoDB Support in <literal>INFORMATION_SCHEMA</literal></title>
 
     <indexterm>
       <primary>information schema tables</primary>

@@ -30,14 +30,14 @@
     <para>
       The seven
       <ulink url="http://dev.mysql.com/doc/refman/5.1/en/information-schema.html">
-      &INFORMATION_SCHEMA; </ulink> tables &INNODB_CMP;,
-      &INNODB_CMP_RESET;, &INNODB_CMPMEM;, &INNODB_CMPMEM_RESET;,
-      &INNODB_TRX;, &INNODB_LOCKS; and &INNODB_LOCK_WAITS; contain live
-      information about compressed &innodb; tables, the compressed
-      &innodb; buffer pool, all transactions currently executing inside
-      &innodb;, the locks that transactions hold and those that are
-      blocking transactions waiting for access to a resource (a table or
-      row).
+      <literal>INFORMATION_SCHEMA</literal> </ulink> tables
+      &INNODB_CMP;, &INNODB_CMP_RESET;, &INNODB_CMPMEM;,
+      &INNODB_CMPMEM_RESET;, &INNODB_TRX;, &INNODB_LOCKS; and
+      &INNODB_LOCK_WAITS; contain live information about compressed
+      &innodb; tables, the compressed &innodb; buffer pool, all
+      transactions currently executing inside &innodb;, the locks that
+      transactions hold and those that are blocking transactions waiting
+      for access to a resource (a table or row).
     </para>
 
     <para>

@@ -1100,8 +1100,9 @@
         </para>
 
         <para>
-          The following output from the &INFORMATION_SCHEMA; tables is
-          taken from a somewhat loaded system.
+          The following output from the
+          <literal>INFORMATION_SCHEMA</literal> tables is taken from a
+          somewhat loaded system.
         </para>
 
         <para>

@@ -1733,15 +1734,15 @@
       <para>
         For performance reasons, and to minimize the chance of
         misleading <literal>JOIN</literal>s between the
-        &INFORMATION_SCHEMA; tables, &innodb; collects the required
-        transaction and locking information into an intermediate buffer
-        whenever a <literal>SELECT</literal> on any of the tables is
-        issued. This buffer is refreshed only if more than 0.1 seconds
-        has elapsed since the last time the buffer was read. The data
-        needed to fill the three tables is fetched atomically and
-        consistently and is saved in this global internal buffer,
-        forming a point-in-time <quote>snapshot</quote>. If multiple
-        table accesses occur within 0.1 seconds (as they almost
+        <literal>INFORMATION_SCHEMA</literal> tables, &innodb; collects
+        the required transaction and locking information into an
+        intermediate buffer whenever a <literal>SELECT</literal> on any
+        of the tables is issued. This buffer is refreshed only if more
+        than 0.1 seconds has elapsed since the last time the buffer was
+        read. The data needed to fill the three tables is fetched
+        atomically and consistently and is saved in this global internal
+        buffer, forming a point-in-time <quote>snapshot</quote>. If
+        multiple table accesses occur within 0.1 seconds (as they almost
         certainly do when &mysql; processes a join among these tables),
         then the same snapshot is used to satisfy the query.
       </para>

@@ -1780,16 +1781,17 @@
 
       <indexterm>
         <primary>&PROCESSLIST;</primary>
-        <secondary>possible inconsistency with &INFORMATION_SCHEMA; tables</secondary>
+        <secondary>possible inconsistency with <literal>INFORMATION_SCHEMA</literal> tables</secondary>
       </indexterm>
 
       <para>
         As just described, while the transaction and locking data is
-        correct and consistent when these &INFORMATION_SCHEMA; tables
-        are populated, the underlying data changes so fast that similar
-        glimpses at other, similarly fast-changing data, may not be in
-        sync. Thus, you should be careful in comparing the data in the
-        &innodb; transaction and locking tables with that in the
+        correct and consistent when these
+        <literal>INFORMATION_SCHEMA</literal> tables are populated, the
+        underlying data changes so fast that similar glimpses at other,
+        similarly fast-changing data, may not be in sync. Thus, you
+        should be careful in comparing the data in the &innodb;
+        transaction and locking tables with that in the
         <ulink url='http://dev.mysql.com/doc/refman/5.1/en/processlist-table.html'>
         &mysql; table &PROCESSLIST; </ulink>. The data from the
         &PROCESSLIST; table does not come from the same snapshot as the


Thread
svn commit - mysqldoc@oter02: r25775 - trunk/innodb-plugin-1.0jon.stephens7 Apr