</para>
  </sect1>

  <sect1 id="transaction-iso">
   <title>Transaction Isolation</title>

   <indexterm>
    <primary>transaction isolation</primary>
   </indexterm>

   <para>
    The <acronym>SQL</acronym> standard defines four levels of
    transaction isolation.  The most strict is Serializable,
    which is defined by the standard in a paragraph which says that any
    concurrent execution of a set of Serializable transactions is guaranteed
    to produce the same effect as running them one at a time in some order.
    The other three levels are defined in terms of phenomena, resulting from
    interaction between concurrent transactions, which must not occur at
    each level.  The standard notes that due to the definition of
    Serializable, none of these phenomena are possible at that level.  (This
    is hardly surprising -- if the effect of the transactions must be
    consistent with having been run one at a time, how could you see any
    phenomena caused by interactions?)
   </para>

   <para>
    The phenomena which are prohibited at various levels are:

    <variablelist>
     <varlistentry>
      <term>
       dirty read
       <indexterm><primary>dirty read</primary></indexterm>
      </term>
      <listitem>
       <para>
        A transaction reads data written by a concurrent uncommitted transaction.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>
       nonrepeatable read
       <indexterm><primary>nonrepeatable read</primary></indexterm>
      </term>
      <listitem>
       <para>
        A transaction re-reads data it has previously read and finds that data
        has been modified by another transaction (that committed since the
        initial read).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>
       phantom read
       <indexterm><primary>phantom read</primary></indexterm>
      </term>
      <listitem>
       <para>
        A transaction re-executes a query returning a set of rows that satisfy a
        search condition and finds that the set of rows satisfying the condition
        has changed due to another recently-committed transaction.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>
       serialization anomaly
       <indexterm><primary>serialization anomaly</primary></indexterm>
      </term>
      <listitem>
       <para>
        The result of successfully committing a group of transactions
        is inconsistent with all possible orderings of running those
        transactions one at a time.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>

   <para>
    <indexterm>
     <primary>transaction isolation level</primary>
    </indexterm>
    The SQL standard and PostgreSQL-implemented transaction isolation levels
    are described in <xref linkend="mvcc-isolevel-table"/>.
   </para>

    <table tocentry="1" id="mvcc-isolevel-table">
     <title>Transaction Isolation Levels</title>
     <tgroup cols="5">
      <thead>
       <row>
        <entry>
         Isolation Level
        </entry>
        <entry>
         Dirty Read
        </entry>
        <entry>
         Nonrepeatable Read
        </entry>
        <entry>
         Phantom Read
        </entry>
        <entry>
         Serialization Anomaly
        </entry>
       </row>
      </thead>
      <tbody>
       <row>
        <entry>
         Read uncommitted
        </entry>
        <entry>
         Allowed, but not in PG
        </entry>
        <entry>
         Possible
        </entry>
        <entry>
         Possible
        </entry>
        <entry>
         Possible
        </entry>
       </row>

       <row>
        <entry>
         Read committed
        </entry>
        <entry>
         Not possible
        </entry>
        <entry>
         Possible
        </entry>
        <entry>
         Possible
        </entry>
        <entry>
         Possible
        </entry>