several separate updates involved to accomplish
    this rather simple operation.  Our bank's officers will want to be
    assured that either all these updates happen, or none of them happen.
    It would certainly not do for a system failure to result in Bob
    receiving $100.00 that was not debited from Alice.  Nor would Alice long
    remain a happy customer if she was debited without Bob being credited.
    We need a guarantee that if something goes wrong partway through the
    operation, none of the steps executed so far will take effect.  Grouping
    the updates into a <firstterm>transaction</firstterm> gives us this guarantee.
    A transaction is said to be <firstterm>atomic</firstterm>: from the point of
    view of other transactions, it either happens completely or not at all.
   </para>

   <para>
    We also want a
    guarantee that once a transaction is completed and acknowledged by
    the database system, it has indeed been permanently recorded
    and won't be lost even if a crash ensues shortly thereafter.
    For example, if we are recording a cash withdrawal by Bob,
    we do not want any chance that the debit to his account will
    disappear in a crash just after he walks out the bank door.
    A transactional database guarantees that all the updates made by
    a transaction are logged in permanent storage (i.e., on disk) before
    the transaction is reported complete.
   </para>

   <para>
    Another important property of transactional databases is closely
    related to the notion of atomic updates: when multiple transactions
    are running concurrently, each one should not be able to see the
    incomplete changes made by others.  For example, if one transaction
    is busy totalling all the branch balances, it would not do for it
    to include the debit from Alice's branch but not the credit to
    Bob's branch, nor vice versa.  So transactions must be all-or-nothing
    not only in terms of their permanent effect on the database, but
    also in terms of their visibility as they happen.  The updates made
    so far by an open transaction are invisible to other transactions
    until the transaction completes, whereupon all the updates become
    visible simultaneously.
   </para>

   <para>
    In <productname>PostgreSQL</productname>, a transaction is set up by surrounding
    the SQL commands of the transaction with
    <command>BEGIN</command> and <command>COMMIT</command> commands.  So our banking
    transaction would actually look like:

<programlisting>
BEGIN;
UPDATE accounts SET balance = balance - 100.00
    WHERE name = 'Alice';
-- etc etc
COMMIT;
</programlisting>
   </para>

   <para>
    If, partway through the transaction, we decide we do not want to
    commit (perhaps we just noticed that Alice's balance went negative),
    we can issue the command <command>ROLLBACK</command> instead of
    <command>COMMIT</command>, and all our updates so far will be canceled.
   </para>

   <para>
    <productname>PostgreSQL</productname> actually treats every SQL statement as being
    executed within a transaction.  If you do not issue a <command>BEGIN</command>
    command,
    then each individual statement has an implicit <command>BEGIN</command> and
    (if successful) <command>COMMIT</command> wrapped around it.  A group of
    statements surrounded by <command>BEGIN</command> and <command>COMMIT</command>
    is sometimes called a <firstterm>transaction block</firstterm>.
   </para>

   <note>
    <para>
     Some client libraries issue <command>BEGIN</command> and <command>COMMIT</command>
     commands automatically, so that you might get the effect of transaction
     blocks without asking.  Check the documentation for the interface
     you are using.
    </para>
   </note>

   <para>
    It's possible to control the statements in a transaction in a more
    granular fashion through the use of <firstterm>savepoints</firstterm>.  Savepoints
    allow you to selectively discard parts