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 user to specify various
    combinations of <command>INSERT</command>, <command>UPDATE</command>
    and <command>DELETE</command> subcommands. A <command>MERGE</command>
    command with both <command>INSERT</command> and <command>UPDATE</command>
    subcommands looks similar to <command>INSERT</command> with an
    <literal>ON CONFLICT DO UPDATE</literal> clause but does not
    guarantee that either <command>INSERT</command> or
    <command>UPDATE</command> will occur.
    If <command>MERGE</command> attempts an <command>UPDATE</command> or
    <command>DELETE</command> and the row is concurrently updated but
    the join condition still passes for the current target and the
    current source tuple, then <command>MERGE</command> will behave
    the same as the <command>UPDATE</command> or
    <command>DELETE</command> commands and perform its action on the
    updated version of the row.  However, because <command>MERGE</command>
    can specify several actions and they can be conditional, the
    conditions for each action are re-evaluated on the updated version of
    the row, starting from the first action, even if the action that had
    originally matched appears later in the list of actions.
    On the other hand, if the row is concurrently updated so that the join
    condition fails, then <command>MERGE</command> will evaluate the
    command's <literal>NOT MATCHED BY SOURCE</literal> and
    <literal>NOT MATCHED [BY TARGET]</literal> actions next, and execute
    the first one of each kind that succeeds.
    If the row is concurrently deleted, then <command>MERGE</command>
    will evaluate the command's <literal>NOT MATCHED [BY TARGET]</literal>
    actions, and execute the first one that succeeds.
    If <command>MERGE</command> attempts an <command>INSERT</command>
    and a unique index is present and a duplicate row is concurrently
    inserted, then a uniqueness violation error is raised;
    <command>MERGE</command> does not attempt to avoid 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