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> query sees
    a snapshot of the database as of the instant the query begins to
    run.   However, <command>SELECT</command> does see the effects
    of previous updates executed within its own transaction, even
    though they are not yet committed.  Also note that two successive
    <command>SELECT</command> commands can see different data, even
    though they are within a single transaction, if other transactions
    commit changes after the first <command>SELECT</command> starts and
    before the second <command>SELECT</command> starts.
   </para>

   <para>
    <command>UPDATE</command>, <command>DELETE</command>, <command>SELECT
    FOR UPDATE</command>, and <command>SELECT FOR SHARE</command> commands
    behave the same as <command>SELECT</command>
    in terms of searching for target rows: they will only find target rows
    that were committed as of the command start time.  However, such a target
    row might have already been updated (or deleted or locked) by
    another concurrent transaction by the time it is found.  In this case, the
    would-be updater will wait for the first updating transaction to commit or
    roll back (if it is still in progress).  If the first updater rolls back,
    then its effects are negated and the second updater can proceed with
    updating the originally found row.  If the first updater commits, the
    second updater will ignore the row if the first updater deleted it,
    otherwise it will attempt to apply its operation to the updated version of
    the row.  The search condition of the command (the <literal>WHERE</literal> clause) is
    re-evaluated to see if the updated version of the row still matches the
    search condition.  If so, the second updater proceeds with its operation
    using the updated version of the row.  In the case of
    <command>SELECT FOR UPDATE</command> and <command>SELECT FOR
    SHARE</command>, this means it is the updated version of the row that is
    locked and returned to the client.
   </para>

   <para>
    <command>INSERT</command> with an <literal>ON CONFLICT DO UPDATE</literal> clause
    behaves similarly. In Read Committed mode, each row proposed for insertion
    will either insert or update. Unless there are unrelated errors, one of
    those two outcomes is guaranteed.  If a conflict originates in another
    transaction whose effects are not yet visible to the <command>INSERT</command>,
    the <command>UPDATE</command> clause will affect that row,
    even though possibly <emphasis>no</emphasis> version of that row is
    conventionally visible to the command.
   </para>

   <para>
    <command>INSERT</command> with an <literal>ON CONFLICT DO
    NOTHING</literal> clause may have insertion not proceed for a row due to
    the outcome of another transaction whose effects are not visible
    to the <command>INSERT</command> snapshot.  Again, this is only
    the case in Read Committed mode.
   </para>

   <para>
    <command>MERGE</command> allows the