Sophie: postgresql8.4-docs-8.4.12-0.1mdv2010.2 i586

postgresql8.4-docs-8.4.12-0.1mdv2010.2.i586.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>LOCK</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 8.4.12 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="SQL Commands"
HREF="sql-commands.html"><LINK
REL="PREVIOUS"
TITLE="LOAD"
HREF="sql-load.html"><LINK
REL="NEXT"
TITLE="MOVE"
HREF="sql-move.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2012-05-31T23:30:11"></HEAD
><BODY
CLASS="REFENTRY"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
>PostgreSQL 8.4.12 Documentation</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="sql-load.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="sql-load.html"
>Fast Backward</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="sql-move.html"
>Fast Forward</A
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="sql-move.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><H1
><A
NAME="SQL-LOCK"
></A
>LOCK</H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN63797"
></A
><H2
>Name</H2
>LOCK&nbsp;--&nbsp;lock a table</DIV
><A
NAME="AEN63800"
></A
><DIV
CLASS="REFSYNOPSISDIV"
><A
NAME="AEN63802"
></A
><H2
>Synopsis</H2
><PRE
CLASS="SYNOPSIS"
>LOCK [ TABLE ] [ ONLY ] <TT
CLASS="REPLACEABLE"
><I
>name</I
></TT
> [, ...] [ IN <TT
CLASS="REPLACEABLE"
><I
>lockmode</I
></TT
> MODE ] [ NOWAIT ]

where <TT
CLASS="REPLACEABLE"
><I
>lockmode</I
></TT
> is one of:

    ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE
    | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE</PRE
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN63807"
></A
><H2
>Description</H2
><P
>   <TT
CLASS="COMMAND"
>LOCK TABLE</TT
> obtains a table-level lock, waiting
   if necessary for any conflicting locks to be released.  If
   <TT
CLASS="LITERAL"
>NOWAIT</TT
> is specified, <TT
CLASS="COMMAND"
>LOCK
   TABLE</TT
> does not wait to acquire the desired lock: if it
   cannot be acquired immediately, the command is aborted and an
   error is emitted.  Once obtained, the lock is held for the
   remainder of the current transaction.  (There is no <TT
CLASS="COMMAND"
>UNLOCK
   TABLE</TT
> command; locks are always released at transaction
   end.)
  </P
><P
>   When acquiring locks automatically for commands that reference
   tables, <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> always uses the least
   restrictive lock mode possible. <TT
CLASS="COMMAND"
>LOCK TABLE</TT
>
   provides for cases when you might need more restrictive locking.
   For example, suppose an application runs a transaction at the
   Read Committed isolation level and needs to ensure that data in a
   table remains stable for the duration of the transaction. To
   achieve this you could obtain <TT
CLASS="LITERAL"
>SHARE</TT
> lock mode over the
   table before querying. This will prevent concurrent data changes
   and ensure subsequent reads of the table see a stable view of
   committed data, because <TT
CLASS="LITERAL"
>SHARE</TT
> lock mode conflicts with
   the <TT
CLASS="LITERAL"
>ROW EXCLUSIVE</TT
> lock acquired by writers, and your
   <TT
CLASS="COMMAND"
>LOCK TABLE <TT
CLASS="REPLACEABLE"
><I
>name</I
></TT
> IN SHARE MODE</TT
>
   statement will wait until any concurrent holders of <TT
CLASS="LITERAL"
>ROW
   EXCLUSIVE</TT
> mode locks commit or roll back. Thus, once you
   obtain the lock, there are no uncommitted writes outstanding;
   furthermore none can begin until you release the lock.
  </P
><P
>   To achieve a similar effect when running a transaction at the Serializable
   isolation level, you have to execute the <TT
CLASS="COMMAND"
>LOCK TABLE</TT
> statement
   before executing any <TT
CLASS="COMMAND"
>SELECT</TT
> or data modification statement.
   A serializable transaction's view of data will be frozen when its first
   <TT
CLASS="COMMAND"
>SELECT</TT
> or data modification statement begins.  A <TT
CLASS="COMMAND"
>LOCK
   TABLE</TT
> 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.
  </P
><P
>   If a transaction of this sort is going to change the data in the
   table, then it should use <TT
CLASS="LITERAL"
>SHARE ROW EXCLUSIVE</TT
> lock mode
   instead of <TT
CLASS="LITERAL"
>SHARE</TT
> 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 <TT
CLASS="LITERAL"
>SHARE</TT
>
   mode, and then be unable to also acquire <TT
CLASS="LITERAL"
>ROW EXCLUSIVE</TT
>
   mode to actually perform their updates.  (Note that a transaction's
   own locks never conflict, so a transaction can acquire <TT
CLASS="LITERAL"
>ROW
   EXCLUSIVE</TT
> mode when it holds <TT
CLASS="LITERAL"
>SHARE</TT
> mode &mdash; but not
   if anyone else holds <TT
CLASS="LITERAL"
>SHARE</TT
> 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.
  </P
><P
>   More information about the lock modes and locking strategies can be
   found in <A
HREF="explicit-locking.html"
>Section 13.3</A
>.
  </P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN63838"
></A
><H2
>Parameters</H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><TT
CLASS="REPLACEABLE"
><I
>name</I
></TT
></DT
><DD
><P
>      The name (optionally schema-qualified) of an existing table to
      lock.  If <TT
CLASS="LITERAL"
>ONLY</TT
> is specified, only that table is
      locked.  If <TT
CLASS="LITERAL"
>ONLY</TT
> is not specified, the table and all
      its descendant tables (if any) are locked.
     </P
><P
>      The command <TT
CLASS="LITERAL"
>LOCK TABLE a, b;</TT
> is equivalent to
      <TT
CLASS="LITERAL"
>LOCK TABLE a; LOCK TABLE b;</TT
>. The tables are locked
      one-by-one in the order specified in the <TT
CLASS="COMMAND"
>LOCK
      TABLE</TT
> command.
     </P
></DD
><DT
><TT
CLASS="REPLACEABLE"
><I
>lockmode</I
></TT
></DT
><DD
><P
>      The lock mode specifies which locks this lock conflicts with.
      Lock modes are described in <A
HREF="explicit-locking.html"
>Section 13.3</A
>.
     </P
><P
>      If no lock mode is specified, then <TT
CLASS="LITERAL"
>ACCESS
      EXCLUSIVE</TT
>, the most restrictive mode, is used.
     </P
></DD
><DT
><TT
CLASS="LITERAL"
>NOWAIT</TT
></DT
><DD
><P
>      Specifies that <TT
CLASS="COMMAND"
>LOCK TABLE</TT
> 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.
     </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN63866"
></A
><H2
>Notes</H2
><P
>    <TT
CLASS="LITERAL"
>LOCK TABLE ... IN ACCESS SHARE MODE</TT
> requires <TT
CLASS="LITERAL"
>SELECT</TT
>
    privileges on the target table.  All other forms of <TT
CLASS="COMMAND"
>LOCK</TT
>
    require at least one of <TT
CLASS="LITERAL"
>UPDATE</TT
>, <TT
CLASS="LITERAL"
>DELETE</TT
>, or
    <TT
CLASS="LITERAL"
>TRUNCATE</TT
> privileges.
   </P
><P
>    <TT
CLASS="COMMAND"
>LOCK TABLE</TT
> is useless outside a transaction block: the lock
    would remain held only to the completion of the statement.  Therefore
    <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> reports an error if <TT
CLASS="COMMAND"
>LOCK</TT
>
    is used outside a transaction block.
    Use
    <A
HREF="sql-begin.html"
><I
>BEGIN</I
></A
> and
    <A
HREF="sql-commit.html"
><I
>COMMIT</I
></A
>
    (or <A
HREF="sql-rollback.html"
><I
>ROLLBACK</I
></A
>)
    to define a transaction block.
   </P
><P
>   <TT
CLASS="COMMAND"
>LOCK TABLE</TT
> only deals with table-level locks, and so
   the mode names involving <TT
CLASS="LITERAL"
>ROW</TT
> are all misnomers.  These
   mode names should generally be read as indicating the intention of
   the user to acquire row-level locks within the locked table.  Also,
   <TT
CLASS="LITERAL"
>ROW EXCLUSIVE</TT
> mode is a sharable table lock.  Keep in
   mind that all the lock modes have identical semantics so far as
   <TT
CLASS="COMMAND"
>LOCK TABLE</TT
> is concerned, differing only in the rules
   about which modes conflict with which. For information on how to
   acquire an actual row-level lock, see <A
HREF="explicit-locking.html#LOCKING-ROWS"
>Section 13.3.2</A
>
   and the <A
HREF="sql-select.html#SQL-FOR-UPDATE-SHARE"
><I
><I
>FOR UPDATE</I
>/<I
>FOR SHARE</I
> Clause</I
></A
> in the <TT
CLASS="COMMAND"
>SELECT</TT
>
   reference documentation.
  </P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN63890"
></A
><H2
>Examples</H2
><P
>   Obtain a <TT
CLASS="LITERAL"
>SHARE</TT
> lock on a primary key table when going to perform
   inserts into a foreign key table:

</P><PRE
CLASS="PROGRAMLISTING"
>BEGIN WORK;
LOCK TABLE films IN SHARE MODE;
SELECT id FROM films 
    WHERE name = 'Star Wars: Episode I - The Phantom Menace';
-- Do ROLLBACK if record was not returned
INSERT INTO films_user_comments VALUES 
    (_id_, 'GREAT! I was waiting for it for so long!');
COMMIT WORK;</PRE
><P>
  </P
><P
>   Take a <TT
CLASS="LITERAL"
>SHARE ROW EXCLUSIVE</TT
> lock on a primary key table when going to perform
   a delete operation:

</P><PRE
CLASS="PROGRAMLISTING"
>BEGIN WORK;
LOCK TABLE films IN SHARE ROW EXCLUSIVE MODE;
DELETE FROM films_user_comments WHERE id IN
    (SELECT id FROM films WHERE rating &lt; 5);
DELETE FROM films WHERE rating &lt; 5;
COMMIT WORK;</PRE
><P>
  </P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN63898"
></A
><H2
>Compatibility</H2
><P
>   There is no <TT
CLASS="COMMAND"
>LOCK TABLE</TT
> in the SQL standard,
   which instead uses <TT
CLASS="COMMAND"
>SET TRANSACTION</TT
> to specify
   concurrency levels on transactions.  <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> supports that too;
   see <A
HREF="sql-set-transaction.html"
><I
>SET TRANSACTION</I
></A
> for details.
  </P
><P
>   Except for <TT
CLASS="LITERAL"
>ACCESS SHARE</TT
>, <TT
CLASS="LITERAL"
>ACCESS EXCLUSIVE</TT
>,
   and <TT
CLASS="LITERAL"
>SHARE UPDATE EXCLUSIVE</TT
> lock modes, the
   <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> lock modes and the
   <TT
CLASS="COMMAND"
>LOCK TABLE</TT
> syntax are compatible with those
   present in <SPAN
CLASS="PRODUCTNAME"
>Oracle</SPAN
>.
  </P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="sql-load.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="sql-move.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>LOAD</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="sql-commands.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>MOVE</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>