appropriate modes to ensure that referenced
    tables are not dropped or modified in incompatible ways while the
    command executes.  (For example, <command>TRUNCATE</command> cannot safely be
    executed concurrently with other operations on the same table, so it
    obtains an <literal>ACCESS EXCLUSIVE</literal> lock on the table to
    enforce that.)
   </para>

   <para>
    To examine a list of the currently outstanding locks in a database
    server, use the
    <link linkend="view-pg-locks"><structname>pg_locks</structname></link>
    system view. For more information on monitoring the status of the lock
    manager subsystem, refer to <xref linkend="monitoring"/>.
   </para>

  <sect2 id="locking-tables">
   <title>Table-Level Locks</title>

   <indexterm zone="locking-tables">
    <primary>LOCK</primary>
   </indexterm>

   <para>
    The list below shows the available lock modes and the contexts in
    which they are used automatically by
    <productname>PostgreSQL</productname>.  You can also acquire any
    of these locks explicitly with the command <xref
    linkend="sql-lock"/>.
    Remember that all of these lock modes are table-level locks,
    even if the name contains the word
    <quote>row</quote>; the names of the lock modes are historical.
    To some extent the names reflect the typical usage of each lock
    mode &mdash; but the semantics are all the same.  The only real difference
    between one lock mode and another is the set of lock modes with
    which each conflicts (see <xref linkend="table-lock-compatibility"/>).
    Two transactions cannot hold locks of conflicting
    modes on the same table at the same time.  (However, a transaction
    never conflicts with itself.  For example, it might acquire
    <literal>ACCESS EXCLUSIVE</literal> lock and later acquire
    <literal>ACCESS SHARE</literal> lock on the same table.)  Non-conflicting
    lock modes can be held concurrently by many transactions.  Notice in
    particular that some lock modes are self-conflicting (for example,
    an <literal>ACCESS EXCLUSIVE</literal> lock cannot be held by more than one
    transaction at a time) while others are not self-conflicting (for example,
    an <literal>ACCESS SHARE</literal> lock can be held by multiple transactions).
   </para>

     <variablelist>
      <title>Table-Level Lock Modes</title>
      <varlistentry>
       <term>
        <literal>ACCESS SHARE</literal> (<literal>AccessShareLock</literal>)
       </term>
       <listitem>
        <para>
         Conflicts with the <literal>ACCESS EXCLUSIVE</literal> lock
         mode only.
        </para>

        <para>
         The <command>SELECT</command> command acquires a lock of this mode on
         referenced tables.  In general, any query that only <emphasis>reads</emphasis> a table
         and does not modify it will acquire this lock mode.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term>
        <literal>ROW SHARE</literal> (<literal>RowShareLock</literal>)
       </term>
       <listitem>
        <para>
         Conflicts with the <literal>EXCLUSIVE</literal> and
         <literal>ACCESS EXCLUSIVE</literal> lock modes.
        </para>

        <para>
         The <command>SELECT</command> command acquires a lock of this mode
         on all tables on which one of the <option>FOR UPDATE</option>,
         <option>FOR NO KEY UPDATE</option>,
         <option>FOR SHARE</option>, or
         <option>FOR KEY SHARE</option> options is specified
         (in addition to <literal>ACCESS SHARE</literal> locks on any other
         tables that are referenced without any explicit
         <option>FOR ...</option> locking option).
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term>
        <literal>ROW EXCLUSIVE</literal> (<literal>RowExclusiveLock</literal>)
       </term>
       <listitem>
        <para>
         Conflicts with the <literal>SHARE</literal>,