the <command>LOCK TABLE</command> statement
   before executing any <command>SELECT</command> or data modification statement.
   A <literal>REPEATABLE READ</literal> or <literal>SERIALIZABLE</literal> transaction's
   view of data will be frozen when its first
   <command>SELECT</command> or data modification statement begins.  A <command>LOCK
   TABLE</command> later in the transaction will still prevent concurrent writes
   &mdash; but it won't ensure that what the transaction reads corresponds to
   the latest committed values.
  </para>

  <para>
   If a transaction of this sort is going to change the data in the
   table, then it should use <literal>SHARE ROW EXCLUSIVE</literal> lock mode
   instead of <literal>SHARE</literal> mode.  This ensures that only one
   transaction of this type runs at a time.  Without this, a deadlock
   is possible: two transactions might both acquire <literal>SHARE</literal>
   mode, and then be unable to also acquire <literal>ROW EXCLUSIVE</literal>
   mode to actually perform their updates.  (Note that a transaction's
   own locks never conflict, so a transaction can acquire <literal>ROW
   EXCLUSIVE</literal> mode when it holds <literal>SHARE</literal> mode &mdash; but not
   if anyone else holds <literal>SHARE</literal> mode.)  To avoid deadlocks,
   make sure all transactions acquire locks on the same objects in the
   same order, and if multiple lock modes are involved for a single
   object, then transactions should always acquire the most
   restrictive mode first.
  </para>

  <para>
   More information about the lock modes and locking strategies can be
   found in <xref linkend="explicit-locking"/>.
  </para>
 </refsect1>

 <refsect1>
  <title>Parameters</title>

  <variablelist>
   <varlistentry>
    <term><replaceable class="parameter">name</replaceable></term>
    <listitem>
     <para>
      The name (optionally schema-qualified) of an existing table to
      lock. If <literal>ONLY</literal> is specified before the table name, only that
      table is locked. If <literal>ONLY</literal> is not specified, the table and all
      its descendant tables (if any) are locked.  Optionally, <literal>*</literal>
      can be specified after the table name to explicitly indicate that
      descendant tables are included.
     </para>

     <para>
      The command <literal>LOCK TABLE a, b;</literal> is equivalent to
      <literal>LOCK TABLE a; LOCK TABLE b;</literal>. The tables are locked
      one-by-one in the order specified in the <command>LOCK
      TABLE</command> command.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">lockmode</replaceable></term>
    <listitem>
     <para>
      The lock mode specifies which locks this lock conflicts with.
      Lock modes are described in <xref linkend="explicit-locking"/>.
     </para>

     <para>
      If no lock mode is specified, then <literal>ACCESS
      EXCLUSIVE</literal>, the most restrictive mode, is used.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>NOWAIT</literal></term>
    <listitem>
     <para>
      Specifies that <command>LOCK TABLE</command> should not wait for
      any conflicting locks to be released: if the specified lock(s)
      cannot be acquired immediately without waiting, the transaction
      is aborted.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </refsect1>

 <refsect1>
  <title>Notes</title>

   <para>
    To lock a table, the user must have the right privilege for the specified
    <replaceable class="parameter">lockmode</replaceable>.
    If the user has <literal>MAINTAIN</literal>,
    <literal>UPDATE</literal>, <literal>DELETE</literal>, or
    <literal>TRUNCATE</literal> privileges on the table, any <replaceable
    class="parameter">lockmode</replaceable> is permitted. If the user has
    <literal>INSERT</literal>