<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>
       </row>

       <row>
        <entry>
         Repeatable read
        </entry>
        <entry>
         Not possible
        </entry>
        <entry>
         Not possible
        </entry>
        <entry>
         Allowed, but not in PG
        </entry>
        <entry>
         Possible
        </entry>
       </row>

       <row>
        <entry>
         Serializable
        </entry>
        <entry>
         Not possible
        </entry>
        <entry>
         Not possible
        </entry>
        <entry>
         Not possible
        </entry>
        <entry>
         Not possible
        </entry>
       </row>
      </tbody>
     </tgroup>
    </table>

   <para>
    In <productname>PostgreSQL</productname>, you can request any of
    the four standard transaction isolation levels, but internally only
    three distinct isolation levels are implemented, i.e., PostgreSQL's
    Read Uncommitted mode behaves like Read Committed.  This is because
    it is the only sensible way to map the standard isolation levels to
    PostgreSQL's multiversion concurrency control architecture.
   </para>

   <para>
    The table also shows that PostgreSQL's Repeatable Read implementation
    does not allow phantom reads.  This is acceptable under the SQL
    standard because the standard specifies which anomalies must
    <emphasis>not</emphasis> occur at certain isolation levels;  higher
    guarantees are acceptable.
    The behavior of the available isolation levels is detailed in the
    following subsections.
   </para>

   <para>
    To set the transaction isolation level of a transaction, use the
    command <xref linkend="sql-set-transaction"/>.
   </para>

   <important>
     <para>
       Some <productname>PostgreSQL</productname> data types and functions have
       special rules regarding transactional behavior.  In particular, changes
       made to a sequence (and therefore the counter of a
       column declared using <type>serial</type>) are immediately visible
       to all other transactions and are not rolled back if the transaction
       that made the changes aborts.  See <xref linkend="functions-sequence"/>
       and <xref linkend="datatype-serial"/>.
     </para>
   </important>

  <sect2 id="xact-read-committed">
   <title>Read Committed Isolation Level</title>

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

   <indexterm>
    <primary>read committed</primary>
   </indexterm>

   <para>
    <firstterm>Read Committed</firstterm> is the default isolation
    level in <productname>PostgreSQL</productname>.  When a transaction
    uses this isolation level, a <command>SELECT</command> query
    (without a <literal>FOR UPDATE/SHARE</literal> clause) sees only data
    committed before the query began; it never sees either uncommitted
    data or changes committed by concurrent transactions during the query's
    execution.  In effect, a <command>SELECT</command>