List:Commits« Previous MessageNext Message »
From:paul Date:December 18 2005 5:24am
Subject:svn commit - mysqldoc@docsrva: r589 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2005-12-18 06:24:44 +0100 (Sun, 18 Dec 2005)
New Revision: 589

Log:
 r4896@frost:  paul | 2005-12-17 23:24:11 -0600
 De-cruft.


Modified:
   trunk/
   trunk/refman-4.1/innodb.xml
   trunk/refman-4.1/storage-engines.xml
   trunk/refman-5.0/innodb.xml
   trunk/refman-5.0/storage-engines.xml
   trunk/refman-5.1/innodb.xml
   trunk/refman-5.1/storage-engines.xml


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

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2005-12-18 05:24:27 UTC (rev 588)
+++ trunk/refman-4.1/innodb.xml	2005-12-18 05:24:44 UTC (rev 589)
@@ -5847,11 +5847,13 @@
         difficult to determine. All InnoDB 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>
 
 <programlisting>
 SELECT COUNT(*) FROM t WHERE a_non_indexed_column &lt;&gt; 12345;
 </programlisting>
 
+      <para>
         takes more time than it <quote>should</quote> take. (In the
         query above we are <quote>fooling</quote> the SQL optimizer into
         scanning the clustered index, rather than a secondary index.)

Modified: trunk/refman-4.1/storage-engines.xml
===================================================================
--- trunk/refman-4.1/storage-engines.xml	2005-12-18 05:24:27 UTC (rev 588)
+++ trunk/refman-4.1/storage-engines.xml	2005-12-18 05:24:44 UTC (rev 589)
@@ -3526,6 +3526,7 @@
       4.1.11. This engine acts as a <quote>black hole</quote> that
       accepts data but throws it away and does not store it. Retrievals
       always return the empty set:
+    </para>
 
 <programlisting>
 mysql&gt; <userinput>CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;</userinput>
@@ -3538,7 +3539,6 @@
 mysql&gt; <userinput>SELECT * FROM test;</userinput>
 Empty set (0.00 sec)
 </programlisting>
-    </para>
 
     <para>
       When you create a <literal>BLACKHOLE</literal> table, the server
@@ -3569,11 +3569,11 @@
       data, but if the binary log is enabled, the SQL statements are
       logged (and replicated to slave servers). This can be useful as a
       repeater or filter mechanism. For example, suppose that your
-      application requires slave-side filtering rules, but transfering
-      all binlog data to the slave first results in too much traffic. In
-      such a case, it is possible to set up on the master host a
-      <quote>dummy</quote> slave process whose default storage engine is
-      <literal>BLACKHOLE</literal>, depicted as follows:
+      application requires slave-side filtering rules, but transferring
+      all binary log data to the slave first results in too much
+      traffic. In such a case, it is possible to set up on the master
+      host a <quote>dummy</quote> slave process whose default storage
+      engine is <literal>BLACKHOLE</literal>, depicted as follows:
     </para>
 
     <mediaobject>
@@ -3591,7 +3591,7 @@
       <literal>mysqld</literal> process acts as a slave, applying the
       desired combination of <literal>replicate-do</literal> and
       <literal>replicate-ignore</literal> rules, and writes a new,
-      filtered binlog of its own. (See
+      filtered binary log of its own. (See
       <xref linkend="replication-options"/>.) This filtered log is
       provided to the slave.
     </para>
@@ -3607,34 +3607,34 @@
     <para>
       Other possible uses for the <literal>BLACKHOLE</literal> storage
       engine include:
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            Verification of dumpfile syntax.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Verification of dumpfile syntax.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Measurement of the overhead from binary logging, by
-            comparing performance using <literal>BLACKHOLE</literal>
-            with and without binary logging enabled.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Measurement of the overhead from binary logging, by comparing
+          performance using <literal>BLACKHOLE</literal> with and
+          without binary logging enabled.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            since <literal>BLACKHOLE</literal> is essentially a
-            <quote>no-op</quote> storage engine, it could be used for
-            finding performance bottlenecks not related to the storage
-            engine itself.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          since <literal>BLACKHOLE</literal> is essentially a
+          <quote>no-op</quote> storage engine, it could be used for
+          finding performance bottlenecks not related to the storage
+          engine itself.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
   </section>
 

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2005-12-18 05:24:27 UTC (rev 588)
+++ trunk/refman-5.0/innodb.xml	2005-12-18 05:24:44 UTC (rev 589)
@@ -112,19 +112,19 @@
 
     <para>
       <emphasis role="bold">Additional resources</emphasis>
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            For the <literal>InnoDB</literal> storage engine, there's a
-            dedicated forum available on
-            <ulink url="http://forums.mysql.com/list.php?22"/>.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          For the <literal>InnoDB</literal> storage engine, there's a
+          dedicated forum available on
+          <ulink url="http://forums.mysql.com/list.php?22"/>.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
   </section>
 
@@ -5797,11 +5797,13 @@
         difficult to determine. All InnoDB 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>
 
 <programlisting>
 SELECT COUNT(*) FROM t WHERE a_non_indexed_column &lt;&gt; 12345;
 </programlisting>
 
+      <para>
         takes more time than it <quote>should</quote> take. (In the
         query above we are <quote>fooling</quote> the SQL optimizer into
         scanning the clustered index, rather than a secondary index.)

Modified: trunk/refman-5.0/storage-engines.xml
===================================================================
--- trunk/refman-5.0/storage-engines.xml	2005-12-18 05:24:27 UTC (rev 588)
+++ trunk/refman-5.0/storage-engines.xml	2005-12-18 05:24:44 UTC (rev 589)
@@ -728,19 +728,19 @@
 
     <para>
       <emphasis role="bold">Additional resources</emphasis>
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            For the <literal>MyISAM</literal> storage engine, there's a
-            dedicated forum available on
-            <ulink url="http://forums.mysql.com/list.php?21"/>.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          For the <literal>MyISAM</literal> storage engine, there's a
+          dedicated forum available on
+          <ulink url="http://forums.mysql.com/list.php?21"/>.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
     <section id="myisam-start">
 
@@ -2033,19 +2033,19 @@
 
       <para>
         <emphasis role="bold">Additional resources</emphasis>
+      </para>
 
-        <itemizedlist>
+      <itemizedlist>
 
-          <listitem>
-            <para>
-              For the <literal>MERGE</literal> storage engine, there's a
-              dedicated forum available on
-              <ulink url="http://forums.mysql.com/list.php?93"/>.
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            For the <literal>MERGE</literal> storage engine, there's a
+            dedicated forum available on
+            <ulink url="http://forums.mysql.com/list.php?93"/>.
+          </para>
+        </listitem>
 
-        </itemizedlist>
-      </para>
+      </itemizedlist>
 
     </section>
 
@@ -2357,19 +2357,19 @@
 
     <para>
       <emphasis role="bold">Additional resources</emphasis>
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            For the <literal>MEMORY</literal> storage engine, there's a
-            dedicated forum available on
-            <ulink url="http://forums.mysql.com/list.php?92"/>.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          For the <literal>MEMORY</literal> storage engine, there's a
+          dedicated forum available on
+          <ulink url="http://forums.mysql.com/list.php?92"/>.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
   </section>
 
@@ -3326,19 +3326,19 @@
 
     <para>
       <emphasis role="bold">Additional resources</emphasis>
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            For the <literal>FEDERATED</literal> storage engine, there's
-            a dedicated forum available on
-            <ulink url="http://forums.mysql.com/list.php?105"/>.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          For the <literal>FEDERATED</literal> storage engine, there's a
+          dedicated forum available on
+          <ulink url="http://forums.mysql.com/list.php?105"/>.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
     <section id="federated-install">
 
@@ -3578,19 +3578,19 @@
 
       <para>
         <emphasis role="bold">Additional resources</emphasis>
+      </para>
 
-        <itemizedlist>
+      <itemizedlist>
 
-          <listitem>
-            <para>
-              For the <literal>FEDERATED</literal> storage engine,
-              there's a dedicated forum available on
-              <ulink url="http://forums.mysql.com/list.php?105"/>.
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            For the <literal>FEDERATED</literal> storage engine, there's
+            a dedicated forum available on
+            <ulink url="http://forums.mysql.com/list.php?105"/>.
+          </para>
+        </listitem>
 
-        </itemizedlist>
-      </para>
+      </itemizedlist>
 
     </section>
 
@@ -3822,19 +3822,19 @@
 
     <para>
       <emphasis role="bold">Additional resources</emphasis>
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            For the <literal>ARCHIVE</literal> storage engine, there's a
-            dedicated forum available on
-            <ulink url="http://forums.mysql.com/list.php?112"/>.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          For the <literal>ARCHIVE</literal> storage engine, there's a
+          dedicated forum available on
+          <ulink url="http://forums.mysql.com/list.php?112"/>.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
   </section>
 
@@ -3934,6 +3934,7 @@
       The <literal>BLACKHOLE</literal> storage engine acts as a
       <quote>black hole</quote> that accepts data but throws it away and
       does not store it. Retrievals always return the empty set:
+    </para>
 
 <programlisting>
 mysql&gt; <userinput>CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;</userinput>
@@ -3946,7 +3947,6 @@
 mysql&gt; <userinput>SELECT * FROM test;</userinput>
 Empty set (0.00 sec)
 </programlisting>
-    </para>
 
     <para>
       When you create a <literal>BLACKHOLE</literal> table, the server
@@ -3977,7 +3977,7 @@
       data, but if the binary log is enabled, the SQL statements are
       logged (and replicated to slave servers). This can be useful as a
       repeater or filter mechanism. For example, suppose that your
-      application requires slave-side filtering rules, but transfering
+      application requires slave-side filtering rules, but transferring
       all binlog data to the slave first results in too much traffic. In
       such a case, it is possible to set up on the master host a
       <quote>dummy</quote> slave process whose default storage engine is
@@ -3999,7 +3999,7 @@
       <literal>mysqld</literal> process acts as a slave, applying the
       desired combination of <literal>replicate-do</literal> and
       <literal>replicate-ignore</literal> rules, and writes a new,
-      filtered binlog of its own. (See
+      filtered binary log of its own. (See
       <xref linkend="replication-options"/>.) This filtered log is
       provided to the slave.
     </para>
@@ -4015,34 +4015,34 @@
     <para>
       Other possible uses for the <literal>BLACKHOLE</literal> storage
       engine include:
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            Verification of dumpfile syntax.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Verification of dumpfile syntax.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Measurement of the overhead from binary logging, by
-            comparing performance using <literal>BLACKHOLE</literal>
-            with and without binary logging enabled.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Measurement of the overhead from binary logging, by comparing
+          performance using <literal>BLACKHOLE</literal> with and
+          without binary logging enabled.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            since <literal>BLACKHOLE</literal> is essentially a
-            <quote>no-op</quote> storage engine, it could be used for
-            finding performance bottlenecks not related to the storage
-            engine itself.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          since <literal>BLACKHOLE</literal> is essentially a
+          <quote>no-op</quote> storage engine, it could be used for
+          finding performance bottlenecks not related to the storage
+          engine itself.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
   </section>
 

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2005-12-18 05:24:27 UTC (rev 588)
+++ trunk/refman-5.1/innodb.xml	2005-12-18 05:24:44 UTC (rev 589)
@@ -112,19 +112,19 @@
 
     <para>
       <emphasis role="bold">Additional resources</emphasis>
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            For the <literal>InnoDB</literal> storage engine, there's a
-            dedicated forum available on
-            <ulink url="http://forums.mysql.com/list.php?22"/>.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          For the <literal>InnoDB</literal> storage engine, there's a
+          dedicated forum available on
+          <ulink url="http://forums.mysql.com/list.php?22"/>.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
   </section>
 
@@ -5757,11 +5757,13 @@
         difficult to determine. All InnoDB 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>
 
 <programlisting>
 SELECT COUNT(*) FROM t WHERE a_non_indexed_column &lt;&gt; 12345;
 </programlisting>
 
+      <para>
         takes more time than it <quote>should</quote> take. (In the
         query above we are <quote>fooling</quote> the SQL optimizer into
         scanning the clustered index, rather than a secondary index.)

Modified: trunk/refman-5.1/storage-engines.xml
===================================================================
--- trunk/refman-5.1/storage-engines.xml	2005-12-18 05:24:27 UTC (rev 588)
+++ trunk/refman-5.1/storage-engines.xml	2005-12-18 05:24:44 UTC (rev 589)
@@ -732,19 +732,19 @@
 
     <para>
       <emphasis role="bold">Additional resources</emphasis>
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            For the <literal>MyISAM</literal> storage engine, there's a
-            dedicated forum available on
-            <ulink url="http://forums.mysql.com/list.php?21"/>.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          For the <literal>MyISAM</literal> storage engine, there's a
+          dedicated forum available on
+          <ulink url="http://forums.mysql.com/list.php?21"/>.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
     <section id="myisam-start">
 
@@ -2033,19 +2033,19 @@
 
       <para>
         <emphasis role="bold">Additional resources</emphasis>
+      </para>
 
-        <itemizedlist>
+      <itemizedlist>
 
-          <listitem>
-            <para>
-              For the <literal>MERGE</literal> storage engine, there's a
-              dedicated forum available on
-              <ulink url="http://forums.mysql.com/list.php?93"/>.
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            For the <literal>MERGE</literal> storage engine, there's a
+            dedicated forum available on
+            <ulink url="http://forums.mysql.com/list.php?93"/>.
+          </para>
+        </listitem>
 
-        </itemizedlist>
-      </para>
+      </itemizedlist>
 
     </section>
 
@@ -2357,19 +2357,19 @@
 
     <para>
       <emphasis role="bold">Additional resources</emphasis>
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            For the <literal>MEMORY</literal> storage engine, there's a
-            dedicated forum available on
-            <ulink url="http://forums.mysql.com/list.php?92"/>.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          For the <literal>MEMORY</literal> storage engine, there's a
+          dedicated forum available on
+          <ulink url="http://forums.mysql.com/list.php?92"/>.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
   </section>
 
@@ -3349,19 +3349,19 @@
 
     <para>
       <emphasis role="bold">Additional resources</emphasis>
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            For the <literal>FEDERATED</literal> storage engine, there's
-            a dedicated forum available on
-            <ulink url="http://forums.mysql.com/list.php?105"/>.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          For the <literal>FEDERATED</literal> storage engine, there's a
+          dedicated forum available on
+          <ulink url="http://forums.mysql.com/list.php?105"/>.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
     <section id="federated-install">
 
@@ -3603,19 +3603,19 @@
 
       <para>
         <emphasis role="bold">Additional resources</emphasis>
+      </para>
 
-        <itemizedlist>
+      <itemizedlist>
 
-          <listitem>
-            <para>
-              For the <literal>FEDERATED</literal> storage engine,
-              there's a dedicated forum available on
-              <ulink url="http://forums.mysql.com/list.php?105"/>.
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            For the <literal>FEDERATED</literal> storage engine, there's
+            a dedicated forum available on
+            <ulink url="http://forums.mysql.com/list.php?105"/>.
+          </para>
+        </listitem>
 
-        </itemizedlist>
-      </para>
+      </itemizedlist>
 
     </section>
 
@@ -3846,19 +3846,19 @@
 
     <para>
       <emphasis role="bold">Additional resources</emphasis>
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            For the <literal>ARCHIVE</literal> storage engine, there's a
-            dedicated forum available on
-            <ulink url="http://forums.mysql.com/list.php?112"/>.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          For the <literal>ARCHIVE</literal> storage engine, there's a
+          dedicated forum available on
+          <ulink url="http://forums.mysql.com/list.php?112"/>.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
   </section>
 
@@ -3958,6 +3958,7 @@
       The <literal>BLACKHOLE</literal> storage engine acts as a
       <quote>black hole</quote> that accepts data but throws it away and
       does not store it. Retrievals always return the empty set:
+    </para>
 
 <programlisting>
 mysql&gt; <userinput>CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;</userinput>
@@ -3970,7 +3971,6 @@
 mysql&gt; <userinput>SELECT * FROM test;</userinput>
 Empty set (0.00 sec)
 </programlisting>
-    </para>
 
     <para>
       When you create a <literal>BLACKHOLE</literal> table, the server
@@ -4001,11 +4001,11 @@
       data, but if the binary log is enabled, the SQL statements are
       logged (and replicated to slave servers). This can be useful as a
       repeater or filter mechanism. For example, suppose that your
-      application requires slave-side filtering rules, but transfering
-      all binlog data to the slave first results in too much traffic. In
-      such a case, it is possible to set up on the master host a
-      <quote>dummy</quote> slave process whose default storage engine is
-      <literal>BLACKHOLE</literal>, depicted as follows:
+      application requires slave-side filtering rules, but transferring
+      all binary log data to the slave first results in too much
+      traffic. In such a case, it is possible to set up on the master
+      host a <quote>dummy</quote> slave process whose default storage
+      engine is <literal>BLACKHOLE</literal>, depicted as follows:
     </para>
 
     <mediaobject>
@@ -4023,7 +4023,7 @@
       <literal>mysqld</literal> process acts as a slave, applying the
       desired combination of <literal>replicate-do</literal> and
       <literal>replicate-ignore</literal> rules, and writes a new,
-      filtered binlog of its own. (See
+      filtered binary log of its own. (See
       <xref linkend="replication-options"/>.) This filtered log is
       provided to the slave.
     </para>
@@ -4039,33 +4039,39 @@
     <para>
       Other possible uses for the <literal>BLACKHOLE</literal> storage
       engine include:
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            Verification of dumpfile syntax.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Verification of dumpfile syntax.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Measurement of the overhead from binary logging, by
-            comparing performance using <literal>BLACKHOLE</literal>
-            with and without binary logging enabled.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Measurement of the overhead from binary logging, by comparing
+          performance using <literal>BLACKHOLE</literal> with and
+          without binary logging enabled.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            since <literal>BLACKHOLE</literal> is essentially a
-            <quote>no-op</quote> storage engine, it could be used for
-            finding performance bottlenecks not related to the storage
-            engine itself.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          since <literal>BLACKHOLE</literal> is essentially a
+          <quote>no-op</quote> storage engine, it could be used for
+          finding performance bottlenecks not related to the storage
+          engine itself.
+        </para>
+      </listitem>
 
-      </itemizedlist>
+    </itemizedlist>
+
+    <para>
+      As of MySQL 5.1.4, the <literal>BLACKHOLE</literal> engine is
+      transaction-aware in the sense that committed transactions are
+      written to the binary log, but rolled-back transactions are not.
     </para>
 
   </section>

Thread
svn commit - mysqldoc@docsrva: r589 - in trunk: . refman-4.1 refman-5.0 refman-5.1paul18 Dec