From: Date: August 12 2005 5:17am Subject: bk commit - mysqldoc@docsrva tree (paul:1.3244) List-Archive: http://lists.mysql.com/internals/28208 Message-Id: <20050812031730.747CD350DA6@frost.snake.net> 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 mysqld 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 mysqld 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 mysqld 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 mysqld 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 mysqld 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 mysqld that the flush has taken place, though it has not. Then the durability of transactions is not