<productname>PostgreSQL</productname>.  See
     <xref linkend="row-lock-compatibility"/> for a complete table of
     row-level lock conflicts.  Note that a transaction can hold
     conflicting locks on the same row, even in different subtransactions;
     but other than that, two transactions can never hold conflicting locks
     on the same row.  Row-level locks do not affect data querying; they
     block only <emphasis>writers and lockers</emphasis> to the same
     row.  Row-level locks are released at transaction end or during
     savepoint rollback, just like table-level locks.

    </para>

     <variablelist>
      <title>Row-Level Lock Modes</title>
      <varlistentry>
       <term>
        <literal>FOR UPDATE</literal>
       </term>
       <listitem>
        <para>
         <literal>FOR UPDATE</literal> causes the rows retrieved by the
         <command>SELECT</command> statement to be locked as though for
         update.  This prevents them from being locked, modified or deleted by
         other transactions until the current transaction ends.  That is,
         other transactions that attempt <command>UPDATE</command>,
         <command>DELETE</command>,
         <command>SELECT FOR UPDATE</command>,
         <command>SELECT FOR NO KEY UPDATE</command>,
         <command>SELECT FOR SHARE</command> or
         <command>SELECT FOR KEY SHARE</command>
         of these rows will be blocked until the current transaction ends;
         conversely, <command>SELECT FOR UPDATE</command> will wait for a
         concurrent transaction that has run any of those commands on the
         same row,
         and will then lock and return the updated row (or no row, if the
         row was deleted).  Within a <literal>REPEATABLE READ</literal> or
         <literal>SERIALIZABLE</literal> transaction,
         however, an error will be thrown if a row to be locked has changed
         since the transaction started.  For further discussion see
         <xref linkend="applevel-consistency"/>.
        </para>
        <para>
         The <literal>FOR UPDATE</literal> lock mode
         is also acquired by any <command>DELETE</command> on a row, and also by an
         <command>UPDATE</command> that modifies the values of certain columns.  Currently,
         the set of columns considered for the <command>UPDATE</command> case are those that
         have a unique index on them that can be used in a foreign key (so partial
         indexes and expressional indexes are not considered), but this may change
         in the future.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term>
        <literal>FOR NO KEY UPDATE</literal>
       </term>
       <listitem>
        <para>
         Behaves similarly to <literal>FOR UPDATE</literal>, except that the lock
         acquired is weaker: this lock will not block
         <literal>SELECT FOR KEY SHARE</literal> commands that attempt to acquire
         a lock on the same rows. This lock mode is also acquired by any
         <command>UPDATE</command> that does not acquire a <literal>FOR UPDATE</literal> lock.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term>
        <literal>FOR SHARE</literal>
       </term>
       <listitem>
        <para>
         Behaves similarly to <literal>FOR NO KEY UPDATE</literal>, except that it
         acquires a shared lock rather than exclusive lock on each retrieved
         row.  A shared lock blocks other transactions from performing
         <command>UPDATE</command>, <command>DELETE</command>,
         <command>SELECT FOR UPDATE</command> or
         <command>SELECT FOR NO KEY UPDATE</command> on these rows, but it does not
         prevent them from performing <command>SELECT FOR SHARE</command> or
         <command>SELECT FOR KEY SHARE</command>.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term>
        <literal>FOR KEY SHARE</literal>