such
    errors by restarting evaluation of <literal>MATCHED</literal>
    conditions.
   </para>

   <para>
    Because of the above rules, it is possible for an updating command to see
    an inconsistent snapshot: it can see the effects of concurrent updating
    commands on the same rows it is trying to update, but it
    does not see effects of those commands on other rows in the database.
    This behavior makes Read Committed mode unsuitable for commands that
    involve complex search conditions; however, it is just right for simpler
    cases.  For example, consider transferring $100 from one account
    to another:

<screen>
BEGIN;
UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 12345;
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 7534;
COMMIT;
</screen>

    If another transaction concurrently tries to change the balance of account
    7534, we clearly want the second statement to start with the updated
    version of the account's row.  Because each command is affecting only a
    predetermined row, letting it see the updated version of the row does
    not create any troublesome inconsistency.
   </para>

   <para>
    More complex usage can produce undesirable results in Read Committed
    mode.  For example, consider a <command>DELETE</command> command
    operating on data that is being both added and removed from its
    restriction criteria by another command, e.g., assume
    <literal>website</literal> is a two-row table with
    <literal>website.hits</literal> equaling <literal>9</literal> and
    <literal>10</literal>:

<screen>
BEGIN;
UPDATE website SET hits = hits + 1;
-- run from another session:  DELETE FROM website WHERE hits = 10;
COMMIT;
</screen>

    The <command>DELETE</command> will have no effect even though
    there is a <literal>website.hits = 10</literal> row before and
    after the <command>UPDATE</command>. This occurs because the
    pre-update row value <literal>9</literal> is skipped, and when the
    <command>UPDATE</command> completes and <command>DELETE</command>
    obtains a lock, the new row value is no longer <literal>10</literal> but
    <literal>11</literal>, which no longer matches the criteria.
   </para>

   <para>
    Because Read Committed mode starts each command with a new snapshot
    that includes all transactions committed up to that instant,
    subsequent commands in the same transaction will see the effects
    of the committed concurrent transaction in any case.  The point
    at issue above is whether or not a <emphasis>single</emphasis> command
    sees an absolutely consistent view of the database.
   </para>

   <para>
    The partial transaction isolation provided by Read Committed mode
    is adequate for many applications, and this mode is fast and simple
    to use;  however, it is not sufficient for all cases.  Applications
    that do complex queries and updates might require a more rigorously
    consistent view of the database than Read Committed mode provides.
   </para>
  </sect2>

  <sect2 id="xact-repeatable-read">
   <title>Repeatable Read Isolation Level</title>

   <indexterm>
    <primary>transaction isolation level</primary>
    <secondary>repeatable read</secondary>
   </indexterm>

   <indexterm>
    <primary>repeatable read</primary>
   </indexterm>

   <para>
    The <firstterm>Repeatable Read</firstterm> isolation level only sees
    data committed before the transaction began; it never sees either
    uncommitted data or changes committed by concurrent transactions during
    the transaction's execution.  (However, each query does see the
    effects of previous updates executed within its own transaction,
    even though they are not yet committed.)  This is a stronger
    guarantee than is required by the <acronym>SQL</acronym> standard
    for this isolation level, and prevents all of the phenomena described
    in <xref linkend="mvcc-isolevel-table"/> except for serialization
    anomalies.  As mentioned