Home • Explore • Blog • CI
☰



postgresql
3rd chunk of `doc/src/sgml/ref/lock.sgml`
7745b2383e2b01f36b9a8f20a4af9206aee3aeee68d34e5c00000001000009a0
 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> privileges on the table, <literal>ROW EXCLUSIVE
    MODE</literal> (or a less-conflicting mode as described in <xref
    linkend="explicit-locking"/>) is permitted. If a user has
    <literal>SELECT</literal> privileges on the table, <literal>ACCESS SHARE
    MODE</literal> is permitted.
   </para>

   <para>
    The user performing the lock on the view must have the corresponding
    privilege on the view.  In addition, by default, the view's owner must
    have the relevant privileges on the underlying base relations, whereas the
    user performing the lock does not need any permissions on the underlying
    base relations.  However, if the view has
    <literal>security_invoker</literal> set to <literal>true</literal>
    (see <link linkend="sql-createview"><command>CREATE VIEW</command></link>),
    the user performing the lock, rather than the view owner, must have the
    relevant privileges on the underlying base relations.
   </para>

   <para>
    <command>LOCK TABLE</command> is useless outside a transaction block: the lock
    would remain held only to the completion of the statement.  Therefore
    <productname>PostgreSQL</productname> reports an error if <command>LOCK</command>
    is used outside a transaction block.
    Use
    <link linkend="sql-begin"><command>BEGIN</command></link> and
    <link linkend="sql-commit"><command>COMMIT</command></link>
    (or <link linkend="sql-rollback"><command>ROLLBACK</command></link>)
Title: LOCK TABLE: Privileges, Views, and Transaction Blocks
Summary
The text details the required privileges for locking a table, stating that users need specific privileges (MAINTAIN, UPDATE, DELETE, or TRUNCATE) to use any lockmode, ROW EXCLUSIVE MODE for INSERT, and ACCESS SHARE MODE for SELECT. It explains that users locking a view must have corresponding privileges, and the view's owner typically needs privileges on the underlying base relations, unless security_invoker is set to true. The text also emphasizes that LOCK TABLE is ineffective outside a transaction block, resulting in an error if used without BEGIN and COMMIT/ROLLBACK statements.