bk commit - mysqldoc@docsrva tree (paul:1.3244)

[paul]

Below is the list of changes that have just been committed into a local
mysqldoc repository of paul. When paul does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html

ChangeSet
  1.3244 05/08/11 22:17:19 paul@stripped +4 -0
  Revert earlier wording change, I goofed.

  refman/innodb.xml
    1.22 05/08/11 22:17:13 paul@stripped +1 -1
    Revert earlier wording change, I goofed.

  refman-5.1/innodb.xml
    1.6 05/08/11 22:17:12 paul@stripped +4 -2
    Sync.

  refman-5.0/innodb.xml
    1.6 05/08/11 22:17:12 paul@stripped +4 -2
    Sync.

  refman-4.1/innodb.xml
    1.14 05/08/11 22:17:11 paul@stripped +1 -1
    Sync.

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	paul
# Host:	frost.snake.net
# Root:	/Volumes/frost2/MySQL/bk/mysqldoc

--- 1.5/refman-5.1/innodb.xml	2005-08-11 07:59:44 -05:00
+++ 1.6/refman-5.1/innodb.xml	2005-08-11 22:17:12 -05:00
@@ -904,8 +904,10 @@
           the value to 0, then any <command>mysqld</command> process
           crash can erase the last second of transactions. If you set
           the value to 2, then only an operating system crash or a power
-          outage can erase the last second of transactions. Note that
-          many operating systems and some disk hardware fail in the
+          outage can erase the last second of transactions. However,
+          InnoDB'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

--- 1.13/refman-4.1/innodb.xml	2005-08-11 07:59:43 -05:00
+++ 1.14/refman-4.1/innodb.xml	2005-08-11 22:17:11 -05:00
@@ -1000,7 +1000,7 @@
           outage can erase the last second of transactions. However,
           InnoDB'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 fail in the
+          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

--- 1.21/refman/innodb.xml	2005-08-11 22:23:15 -05:00
+++ 1.22/refman/innodb.xml	2005-08-11 22:17:13 -05:00
@@ -1000,7 +1000,7 @@
           outage can erase the last second of transactions. However,
           InnoDB'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 fail in the
+          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

--- 1.5/refman-5.0/innodb.xml	2005-08-11 07:59:44 -05:00
+++ 1.6/refman-5.0/innodb.xml	2005-08-11 22:17:12 -05:00
@@ -904,8 +904,10 @@
           the value to 0, then any <command>mysqld</command> process
           crash can erase the last second of transactions. If you set
           the value to 2, then only an operating system crash or a power
-          outage can erase the last second of transactions. Note that
-          many operating systems and some disk hardware fail in the
+          outage can erase the last second of transactions. However,
+          InnoDB'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