transaction cannot modify or lock rows changed by
    other transactions after the repeatable read transaction began.
   </para>

   <para>
    When an application receives this error message, it should abort
    the current transaction and retry the whole transaction from
    the beginning.  The second time through, the transaction will see the
    previously-committed change as part of its initial view of the database,
    so there is no logical conflict in using the new version of the row
    as the starting point for the new transaction's update.
   </para>

   <para>
    Note that only updating transactions might need to be retried; read-only
    transactions will never have serialization conflicts.
   </para>

   <para>
    The Repeatable Read mode provides a rigorous guarantee that each
    transaction sees a completely stable view of the database.  However,
    this view will not necessarily always be consistent with some serial
    (one at a time) execution of concurrent transactions of the same level.
    For example, even a read-only transaction at this level may see a
    control record updated to show that a batch has been completed but
    <emphasis>not</emphasis> see one of the detail records which is logically
    part of the batch because it read an earlier revision of the control
    record.  Attempts to enforce business rules by transactions running at
    this isolation level are not likely to work correctly without careful use
    of explicit locks to block conflicting transactions.
   </para>

   <para>
    The Repeatable Read isolation level is implemented using a technique
    known in academic database literature and in some other database products
    as <firstterm>Snapshot Isolation</firstterm>.  Differences in behavior
    and performance may be observed when compared with systems that use a
    traditional locking technique that reduces concurrency.  Some other
    systems may even offer Repeatable Read and Snapshot Isolation as distinct
    isolation levels with different behavior.  The permitted phenomena that
    distinguish the two techniques were not formalized by database researchers
    until after the SQL standard was developed, and are outside the scope of
    this manual.  For a full treatment, please see
    <xref linkend="berenson95"/>.
   </para>

   <note>
    <para>
     Prior to <productname>PostgreSQL</productname> version 9.1, a request
     for the Serializable transaction isolation level provided exactly the
     same behavior described here.  To retain the legacy Serializable
     behavior, Repeatable Read should now be requested.
    </para>
   </note>
  </sect2>

  <sect2 id="xact-serializable">
   <title>Serializable Isolation Level</title>

   <indexterm>
    <primary>transaction isolation level</primary>
    <secondary>serializable</secondary>
   </indexterm>

   <indexterm>
    <primary>serializable</primary>
   </indexterm>

   <indexterm>
    <primary>predicate locking</primary>
   </indexterm>

   <indexterm>
    <primary>serialization anomaly</primary>
   </indexterm>

   <para>
    The <firstterm>Serializable</firstterm> isolation level provides
    the strictest transaction isolation.  This level emulates serial
    transaction execution for all committed transactions;
    as if transactions had been executed one after another, serially,
    rather than concurrently.  However, like the Repeatable Read level,
    applications using this level must
    be prepared to retry transactions due to serialization failures.
    In fact, this isolation level works exactly the same as Repeatable
    Read except that it also monitors for conditions which could make
    execution of a concurrent set of serializable transactions behave
    in a manner inconsistent with all possible serial (one at a time)
    executions of those transactions.  This monitoring does not
    introduce any blocking beyond that present in repeatable read, but
    there is some overhead to the monitoring,