From eab2ef6164ae2d0e5a72501de9c09474fd94a394 Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Mon, 29 Aug 2011 22:25:17 -0400 Subject: [PATCH] Remove some tabs from README file. Some of the ASCII art expected 8-space tab stops, and some of it expected 4-space tab stops. Per report from YAMAMOTO Takashi. --- src/backend/access/transam/README | 54 +++++++++++++++---------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/src/backend/access/transam/README b/src/backend/access/transam/README index eaac1393b8..c0c9aeaa31 100644 --- a/src/backend/access/transam/README +++ b/src/backend/access/transam/README @@ -59,27 +59,27 @@ For example, consider the following sequence of user commands: In the main processing loop, this results in the following function call sequence: - / StartTransactionCommand; - / StartTransaction; -1) < ProcessUtility; << BEGIN - \ BeginTransactionBlock; - \ CommitTransactionCommand; + / StartTransactionCommand; + / StartTransaction; +1) < ProcessUtility; << BEGIN + \ BeginTransactionBlock; + \ CommitTransactionCommand; - / StartTransactionCommand; -2) / ProcessQuery; << SELECT ... - \ CommitTransactionCommand; - \ CommandCounterIncrement; + / StartTransactionCommand; +2) / ProcessQuery; << SELECT ... + \ CommitTransactionCommand; + \ CommandCounterIncrement; - / StartTransactionCommand; -3) / ProcessQuery; << INSERT ... - \ CommitTransactionCommand; - \ CommandCounterIncrement; + / StartTransactionCommand; +3) / ProcessQuery; << INSERT ... + \ CommitTransactionCommand; + \ CommandCounterIncrement; - / StartTransactionCommand; - / ProcessUtility; << COMMIT -4) < EndTransactionBlock; - \ CommitTransactionCommand; - \ CommitTransaction; + / StartTransactionCommand; + / ProcessUtility; << COMMIT +4) < EndTransactionBlock; + \ CommitTransactionCommand; + \ CommitTransaction; The point of this example is to demonstrate the need for StartTransactionCommand and CommitTransactionCommand to be state smart -- they @@ -87,25 +87,25 @@ should call CommandCounterIncrement between the calls to BeginTransactionBlock and EndTransactionBlock and outside these calls they need to do normal start, commit or abort processing. -Furthermore, suppose the "SELECT * FROM foo" caused an abort condition. In +Furthermore, suppose the "SELECT * FROM foo" caused an abort condition. In this case AbortCurrentTransaction is called, and the transaction is put in aborted state. In this state, any user input is ignored except for transaction-termination statements, or ROLLBACK TO commands. Transaction aborts can occur in two ways: -1) system dies from some internal cause (syntax error, etc) -2) user types ROLLBACK +1) system dies from some internal cause (syntax error, etc) +2) user types ROLLBACK The reason we have to distinguish them is illustrated by the following two situations: - case 1 case 2 - ------ ------ -1) user types BEGIN 1) user types BEGIN -2) user does something 2) user does something -3) user does not like what 3) system aborts for some reason - she sees and types ABORT (syntax error, etc) + case 1 case 2 + ------ ------ +1) user types BEGIN 1) user types BEGIN +2) user does something 2) user does something +3) user does not like what 3) system aborts for some reason + she sees and types ABORT (syntax error, etc) In case 1, we want to abort the transaction and return to the default state. In case 2, there may be more commands coming our way which are part of the