head	1.54;
access;
symbols
	REL9_0_0:1.54
	REL9_1_ALPHA1:1.54
	REL9_0_RC1:1.54
	REL9_0_BETA4:1.54
	REL9_0_STABLE:1.54.0.2
	REL9_0_BETA3:1.54
	REL9_0_BETA2:1.54
	REL7_4_29:1.38
	REL8_0_25:1.45.4.1
	REL8_1_21:1.47
	REL8_2_17:1.48
	REL8_3_11:1.48
	REL8_4_4:1.52
	REL9_0_BETA1:1.54
	REL9_0_ALPHA5_BRANCH:1.53.0.8
	REL9_0_ALPHA5:1.53
	REL7_4_28:1.38
	REL8_0_24:1.45.4.1
	REL8_1_20:1.47
	REL8_2_16:1.48
	REL8_3_10:1.48
	REL8_4_3:1.52
	REL9_0_ALPHA4:1.53
	REL9_0_ALPHA4_BRANCH:1.53.0.6
	REL8_5_ALPHA3:1.53
	REL8_5_ALPHA3_BRANCH:1.53.0.4
	REL7_4_27:1.38
	REL8_0_23:1.45.4.1
	REL8_1_19:1.47
	REL8_2_15:1.48
	REL8_3_9:1.48
	REL8_4_2:1.52
	REL8_5_ALPHA2:1.53
	REL8_5_ALPHA2_BRANCH:1.53.0.2
	REL7_4_26:1.38
	REL8_0_22:1.45.4.1
	REL8_1_18:1.47
	REL8_2_14:1.48
	REL8_3_8:1.48
	REL8_4_1:1.52
	REL8_5_ALPHA1:1.52
	REL8_5_ALPHA1_BRANCH:1.52.0.4
	REL8_4_STABLE:1.52.0.2
	REL8_4_0:1.52
	REL8_4_RC2:1.52
	REL8_4_RC1:1.52
	REL8_4_BETA2:1.52
	REL8_4_BETA1:1.52
	REL7_4_25:1.38
	REL8_0_21:1.45.4.1
	REL8_1_17:1.47
	REL8_2_13:1.48
	REL8_3_7:1.48
	REL7_4_24:1.38
	REL8_0_20:1.45.4.1
	REL8_1_16:1.47
	REL8_2_12:1.48
	REL8_3_6:1.48
	REL7_4_23:1.38
	REL8_0_19:1.45.4.1
	REL8_1_15:1.47
	REL8_2_11:1.48
	REL8_3_5:1.48
	REL7_4_22:1.38
	REL8_0_18:1.45.4.1
	REL8_1_14:1.47
	REL8_2_10:1.48
	REL8_3_4:1.48
	REL7_4_21:1.38
	REL8_0_17:1.45.4.1
	REL8_1_13:1.47
	REL8_2_9:1.48
	REL8_3_3:1.48
	REL7_4_20:1.38
	REL8_0_16:1.45.4.1
	REL8_1_12:1.47
	REL8_2_8:1.48
	REL8_3_2:1.48
	REL8_2_7:1.48
	REL8_3_1:1.48
	REL8_3_STABLE:1.48.0.4
	REL8_3_0:1.48
	REL8_3_RC2:1.48
	REL7_3_21:1.34
	REL7_4_19:1.38
	REL8_0_15:1.45.4.1
	REL8_1_11:1.47
	REL8_2_6:1.48
	REL8_3_RC1:1.48
	REL8_3_BETA4:1.48
	REL8_3_BETA3:1.48
	REL8_3_BETA2:1.48
	REL8_3_BETA1:1.48
	REL7_3_20:1.34
	REL7_4_18:1.38
	REL8_0_14:1.45.4.1
	REL8_1_10:1.47
	REL8_2_5:1.48
	REL7_3_19:1.34
	REL7_4_17:1.38
	REL8_0_13:1.45.4.1
	REL8_1_9:1.47
	REL8_2_4:1.48
	REL8_0_12:1.45.4.1
	REL8_1_8:1.47
	REL8_2_3:1.48
	REL7_3_18:1.34
	REL7_4_16:1.38
	REL8_0_11:1.45.4.1
	REL8_1_7:1.47
	REL8_2_2:1.48
	REL8_0_10:1.45.4.1
	REL8_1_6:1.47
	REL8_2_1:1.48
	REL7_4_15:1.38
	REL7_3_17:1.34
	REL8_2_STABLE:1.48.0.2
	REL8_2_0:1.48
	REL8_2_RC1:1.48
	REL8_2_BETA3:1.48
	REL8_2_BETA2:1.48
	REL8_1_5:1.47
	REL8_0_9:1.45.4.1
	REL7_4_14:1.38
	REL7_3_16:1.34
	REL8_2_BETA1:1.48
	REL7_3_15:1.34
	REL7_4_13:1.38
	REL8_0_8:1.45.4.1
	REL8_1_4:1.47
	REL7_3_14:1.34
	REL7_4_12:1.38
	REL8_0_7:1.45.4.1
	REL8_1_3:1.47
	REL7_3_13:1.34
	REL7_4_11:1.38
	REL8_0_6:1.45.4.1
	REL8_1_2:1.47
	REL7_3_12:1.34
	REL7_4_10:1.38
	REL8_0_5:1.45.4.1
	REL8_1_1:1.47
	REL8_1_STABLE:1.47.0.2
	REL8_1_0:1.47
	REL8_1_0RC1:1.47
	REL8_1_0BETA4:1.47
	REL8_1_0BETA3:1.47
	REL7_3_11:1.34
	REL7_4_9:1.38
	REL8_0_4:1.45.4.1
	REL8_1_0BETA2:1.47
	REL8_1_0BETA1:1.47
	REL7_2_8:1.30
	REL7_3_10:1.34
	REL7_4_8:1.38
	REL8_0_3:1.45.4.1
	REL8_0_2:1.45.4.1
	REL7_2_7:1.30
	REL7_3_9:1.34
	REL7_4_7:1.38
	REL8_0_1:1.45.4.1
	REL8_0_STABLE:1.45.0.4
	REL8_0_0:1.45.0.2
	REL8_0_0RC5:1.45
	REL8_0_0RC4:1.45
	REL8_0_0RC3:1.44
	REL8_0_0RC2:1.44
	REL8_0_0RC1:1.44
	REL8_0_0BETA5:1.44
	REL8_0_0BETA4:1.43
	REL7_4_6:1.38
	REL7_3_8:1.34
	REL7_2_6:1.30
	REL8_0_0BETA3:1.42
	REL8_0_0BETA2:1.42
	REL7_2_5:1.30
	REL7_4_5:1.38
	REL7_3_7:1.34
	REL7_4_4:1.38
	REL8_0_0BETA1:1.42
	REL7_4_3:1.38
	REL7_4_2:1.38
	REL7_3_6:1.34
	REL7_4_1:1.38
	REL7_3_5:1.34
	REL7_4:1.38
	REL7_4_RC2:1.38
	REL7_4_STABLE:1.38.0.2
	REL7_4_RC1:1.38
	REL7_4_BETA5:1.38
	REL7_4_BETA4:1.38
	REL7_4_BETA3:1.38
	REL7_4_BETA2:1.35
	WIN32_DEV:1.35.0.2
	REL7_4_BETA1:1.35
	REL7_3_4:1.34
	REL7_3_2:1.34
	REL7_2_4:1.30
	REL7_3_STABLE:1.34.0.2
	REL7_2_3:1.30
	REL7_2_STABLE:1.30.0.2
	REL7_2:1.30
	REL7_2_RC2:1.30
	REL7_2_RC1:1.30
	REL7_2_BETA5:1.29
	REL7_2_BETA4:1.29
	REL7_2_BETA3:1.28
	REL7_2_BETA2:1.28
	REL7_2_BETA1:1.28
	REL7_1_2:1.23
	REL7_1_STABLE:1.23.0.2
	REL7_1_BETA:1.22
	REL7_1_BETA3:1.23
	REL7_1_BETA2:1.23
	REL7_1:1.23
	REL7_0_PATCHES:1.20.0.2
	REL7_0:1.20
	REL6_5_PATCHES:1.12.0.2
	REL6_5:1.12
	REL6_4:1.3.0.2;
locks; strict;
comment	@# @;


1.54
date	2010.04.03.07.23.01;	author petere;	state Exp;
branches;
next	1.53;

1.53
date	2009.09.18.05.00.42;	author petere;	state Exp;
branches;
next	1.52;

1.52
date	2009.01.12.08.54.25;	author petere;	state Exp;
branches;
next	1.51;

1.51
date	2008.11.14.10.22.47;	author petere;	state Exp;
branches;
next	1.50;

1.50
date	2008.11.04.00.57.19;	author tgl;	state Exp;
branches;
next	1.49;

1.49
date	2008.09.08.00.47.40;	author tgl;	state Exp;
branches;
next	1.48;

1.48
date	2006.09.16.00.30.19;	author momjian;	state Exp;
branches;
next	1.47;

1.47
date	2005.04.28.21.47.10;	author tgl;	state Exp;
branches;
next	1.46;

1.46
date	2005.01.22.23.22.19;	author momjian;	state Exp;
branches;
next	1.45;

1.45
date	2005.01.04.00.39.53;	author tgl;	state Exp;
branches
	1.45.4.1;
next	1.44;

1.44
date	2004.11.15.06.32.15;	author neilc;	state Exp;
branches;
next	1.43;

1.43
date	2004.10.01.16.39.47;	author tgl;	state Exp;
branches;
next	1.42;

1.42
date	2004.03.12.00.52.23;	author neilc;	state Exp;
branches;
next	1.41;

1.41
date	2004.03.11.01.47.35;	author ishii;	state Exp;
branches;
next	1.40;

1.40
date	2003.12.14.00.05.29;	author neilc;	state Exp;
branches;
next	1.39;

1.39
date	2003.11.29.19.51.39;	author pgsql;	state Exp;
branches;
next	1.38;

1.38
date	2003.09.11.21.42.20;	author momjian;	state Exp;
branches;
next	1.37;

1.37
date	2003.09.09.18.28.53;	author tgl;	state Exp;
branches;
next	1.36;

1.36
date	2003.08.31.17.32.23;	author petere;	state Exp;
branches;
next	1.35;

1.35
date	2003.04.26.23.56.51;	author petere;	state Exp;
branches
	1.35.2.1;
next	1.34;

1.34
date	2002.09.21.18.32.54;	author petere;	state Exp;
branches;
next	1.33;

1.33
date	2002.05.30.20.45.18;	author tgl;	state Exp;
branches;
next	1.32;

1.32
date	2002.04.23.02.07.16;	author tgl;	state Exp;
branches;
next	1.31;

1.31
date	2002.04.21.19.02.39;	author thomas;	state Exp;
branches;
next	1.30;

1.30
date	2002.01.18.01.05.43;	author tgl;	state Exp;
branches;
next	1.29;

1.29
date	2001.12.08.03.24.37;	author thomas;	state Exp;
branches;
next	1.28;

1.28
date	2001.09.03.12.57.50;	author petere;	state Exp;
branches;
next	1.27;

1.27
date	2001.08.10.14.30.14;	author momjian;	state Exp;
branches;
next	1.26;

1.26
date	2001.08.04.22.01.38;	author momjian;	state Exp;
branches;
next	1.25;

1.25
date	2001.08.04.19.38.59;	author momjian;	state Exp;
branches;
next	1.24;

1.24
date	2001.07.09.22.18.33;	author tgl;	state Exp;
branches;
next	1.23;

1.23
date	2000.12.25.23.15.26;	author petere;	state Exp;
branches;
next	1.22;

1.22
date	2000.10.05.19.48.18;	author momjian;	state Exp;
branches;
next	1.21;

1.21
date	2000.07.22.04.30.27;	author momjian;	state Exp;
branches;
next	1.20;

1.20
date	2000.03.28.14.35.27;	author thomas;	state Exp;
branches;
next	1.19;

1.19
date	2000.03.24.03.57.06;	author momjian;	state Exp;
branches;
next	1.18;

1.18
date	2000.03.24.01.20.09;	author momjian;	state Exp;
branches;
next	1.17;

1.17
date	2000.03.23.23.16.47;	author momjian;	state Exp;
branches;
next	1.16;

1.16
date	2000.03.23.22.25.35;	author momjian;	state Exp;
branches;
next	1.15;

1.15
date	2000.03.23.21.38.57;	author momjian;	state Exp;
branches;
next	1.14;

1.14
date	99.10.01.15.26.29;	author thomas;	state Exp;
branches;
next	1.13;

1.13
date	99.07.22.15.09.12;	author thomas;	state Exp;
branches;
next	1.12;

1.12
date	99.07.06.17.16.39;	author thomas;	state Exp;
branches;
next	1.11;

1.11
date	99.06.09.13.43.42;	author thomas;	state Exp;
branches;
next	1.10;

1.10
date	99.06.08.20.01.01;	author vadim;	state Exp;
branches;
next	1.9;

1.9
date	99.06.04.15.50.44;	author thomas;	state Exp;
branches;
next	1.8;

1.8
date	99.06.04.04.28.53;	author momjian;	state Exp;
branches;
next	1.7;

1.7
date	99.06.04.04.16.09;	author momjian;	state Exp;
branches;
next	1.6;

1.6
date	99.06.03.19.17.58;	author momjian;	state Exp;
branches;
next	1.5;

1.5
date	99.05.20.05.40.26;	author thomas;	state Exp;
branches;
next	1.4;

1.4
date	98.12.29.02.24.44;	author thomas;	state Exp;
branches;
next	1.3;

1.3
date	98.10.30.19.34.28;	author thomas;	state Exp;
branches;
next	1.2;

1.2
date	98.09.25.13.42.35;	author thomas;	state Exp;
branches;
next	1.1;

1.1
date	98.09.02.03.01.01;	author thomas;	state Exp;
branches;
next	;

1.35.2.1
date	2003.09.07.04.36.45;	author momjian;	state Exp;
branches;
next	;

1.45.4.1
date	2005.01.22.23.23.53;	author momjian;	state Exp;
branches;
next	;


desc
@@


1.54
log
@Remove unnecessary xref endterm attributes and title ids

The endterm attribute is mainly useful when the toolchain does not support
automatic link target text generation for a particular situation.  In  the
past, this was required by the man page tools for all reference page links,
but that is no longer the case, and it now actually gets in the way of
proper automatic link text generation.  The only remaining use cases are
currently xrefs to refsects.
@
text
@<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/lock.sgml,v 1.53 2009/09/18 05:00:42 petere Exp $
PostgreSQL documentation
-->

<refentry id="SQL-LOCK">
 <refmeta>
  <refentrytitle>LOCK</refentrytitle>
  <manvolnum>7</manvolnum>
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 </refmeta>

 <refnamediv>
  <refname>LOCK</refname>
  <refpurpose>lock a table</refpurpose>
 </refnamediv>

 <indexterm zone="sql-lock">
  <primary>LOCK</primary>
 </indexterm>

 <refsynopsisdiv>
<synopsis>
LOCK [ TABLE ] [ ONLY ] <replaceable class="PARAMETER">name</replaceable> [, ...] [ IN <replaceable class="PARAMETER">lockmode</replaceable> MODE ] [ NOWAIT ]

<phrase>where <replaceable class="PARAMETER">lockmode</replaceable> is one of:</phrase>

    ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE
    | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE
</synopsis>
 </refsynopsisdiv>

 <refsect1>
  <title>Description</title>

  <para>
   <command>LOCK TABLE</command> obtains a table-level lock, waiting
   if necessary for any conflicting locks to be released.  If
   <literal>NOWAIT</literal> is specified, <command>LOCK
   TABLE</command> 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 <command>UNLOCK
   TABLE</command> command; locks are always released at transaction
   end.)
  </para>

  <para>
   When acquiring locks automatically for commands that reference
   tables, <productname>PostgreSQL</productname> always uses the least
   restrictive lock mode possible. <command>LOCK TABLE</command>
   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 <literal>SHARE</> 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 <literal>SHARE</> lock mode conflicts with
   the <literal>ROW EXCLUSIVE</> lock acquired by writers, and your
   <command>LOCK TABLE <replaceable
   class="PARAMETER">name</replaceable> IN SHARE MODE</command>
   statement will wait until any concurrent holders of <literal>ROW
   EXCLUSIVE</literal> 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.
  </para>

  <para>
   To achieve a similar effect when running a transaction at the Serializable
   isolation level, you have to execute the <command>LOCK TABLE</> statement
   before executing any <command>SELECT</> or data modification statement.
   A serializable transaction's view of data will be frozen when its first
   <command>SELECT</> or data modification statement begins.  A <command>LOCK
   TABLE</> 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</> lock mode
   instead of <literal>SHARE</> 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</>
   mode, and then be unable to also acquire <literal>ROW EXCLUSIVE</>
   mode to actually perform their updates.  (Note that a transaction's
   own locks never conflict, so a transaction can acquire <literal>ROW
   EXCLUSIVE</> mode when it holds <literal>SHARE</> mode &mdash; but not
   if anyone else holds <literal>SHARE</> 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</> is specified, only that table is
      locked.  If <literal>ONLY</> is not specified, the table and all
      its descendant tables (if any) are locked.
     </para>

     <para>
      The command <literal>LOCK TABLE a, b;</> is equivalent to
      <literal>LOCK TABLE a; LOCK TABLE b;</>. 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>
    <literal>LOCK TABLE ... IN ACCESS SHARE MODE</> requires <literal>SELECT</>
    privileges on the target table.  All other forms of <command>LOCK</>
    require at least one of <literal>UPDATE</>, <literal>DELETE</>, or
    <literal>TRUNCATE</> privileges.
   </para>

   <para>
    <command>LOCK TABLE</> 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</>
    is used outside a transaction block.
    Use
    <xref linkend="sql-begin"> and
    <xref linkend="sql-commit">
    (or <xref linkend="sql-rollback">)
    to define a transaction block.
   </para>

  <para>
   <command>LOCK TABLE</> only deals with table-level locks, and so
   the mode names involving <literal>ROW</> 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,
   <literal>ROW EXCLUSIVE</> mode is a sharable table lock.  Keep in
   mind that all the lock modes have identical semantics so far as
   <command>LOCK TABLE</> 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 <xref linkend="locking-rows">
   and the <xref linkend="sql-for-update-share"
   endterm="sql-for-update-share-title"> in the <command>SELECT</command>
   reference documentation.
  </para>
 </refsect1>
  
 <refsect1>
  <title>Examples</title>

  <para>
   Obtain a <literal>SHARE</> lock on a primary key table when going to perform
   inserts into a foreign key table:

<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;
</programlisting>
  </para>

  <para>
   Take a <literal>SHARE ROW EXCLUSIVE</> lock on a primary key table when going to perform
   a delete operation:

<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;
</programlisting>
  </para>
 </refsect1>

 <refsect1>
  <title>Compatibility</title>

  <para>
   There is no <command>LOCK TABLE</command> in the SQL standard,
   which instead uses <command>SET TRANSACTION</command> to specify
   concurrency levels on transactions.  <productname>PostgreSQL</productname> supports that too;
   see <xref linkend="SQL-SET-TRANSACTION"> for details.
  </para>

  <para>
   Except for <literal>ACCESS SHARE</>, <literal>ACCESS EXCLUSIVE</>,
   and <literal>SHARE UPDATE EXCLUSIVE</> lock modes, the
   <productname>PostgreSQL</productname> lock modes and the
   <command>LOCK TABLE</command> syntax are compatible with those
   present in <productname>Oracle</productname>.
  </para>
 </refsect1>
</refentry>
@


1.53
log
@Easier to translate psql help

Instead of requiring translators to translate the entire SQL command
synopses, change create_help.pl to only require them to translate the
placeholders, and paste those into the synopsis using a printf mechanism.
Make some small updates to the markup to make it easier to parse.

Note: This causes msgmerge of gettext 0.17 to segfault.  You will need
the patch from https://savannah.gnu.org/bugs/?27474 to make it work.
msgmerge usually only runs on babel.postgresql.org, however.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/lock.sgml,v 1.52 2009/01/12 08:54:25 petere Exp $
d8 1
a8 1
  <refentrytitle id="sql-lock-title">LOCK</refentrytitle>
d171 3
a173 3
    <xref linkend="sql-begin" endterm="sql-begin-title"> and
    <xref linkend="sql-commit" endterm="sql-commit-title">
    (or <xref linkend="sql-rollback" endterm="sql-rollback-title">)
d234 1
a234 2
   see <xref linkend="SQL-SET-TRANSACTION"
   endterm="SQL-SET-TRANSACTION-TITLE"> for details.
@


1.52
log
@Add ONLY support to LOCK and TRUNCATE.  By default, these commands are now
recursive.

=> Note this incompatibility in the release notes.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/lock.sgml,v 1.51 2008/11/14 10:22:47 petere Exp $
d26 1
a26 1
where <replaceable class="PARAMETER">lockmode</replaceable> is one of:
@


1.51
log
@Set SQL man pages to be section 7 by default, and only transform them to
another section if required by the platform (instead of the old way of
building them in section "l" and always transforming them to the
platform-specific section).

This speeds up the installation on common platforms, and it avoids some
funny business with the man page tools and build process.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/lock.sgml,v 1.50 2008/11/04 00:57:19 tgl Exp $
d24 1
a24 1
LOCK [ TABLE ] <replaceable class="PARAMETER">name</replaceable> [, ...] [ IN <replaceable class="PARAMETER">lockmode</replaceable> MODE ] [ NOWAIT ]
d112 3
a114 1
      lock.
@


1.50
log
@Disallow LOCK TABLE outside a transaction block (or function), since this case
almost certainly represents user error.  Per a gripe from Sebastian Böhm
and subsequent discussion.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/lock.sgml,v 1.49 2008/09/08 00:47:40 tgl Exp $
d9 1
@


1.49
log
@Create a separate grantable privilege for TRUNCATE, rather than having it be
always owner-only.  The TRUNCATE privilege works identically to the DELETE
privilege so far as interactions with the rest of the system go.

Robert Haas
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/lock.sgml,v 1.48 2006/09/16 00:30:19 momjian Exp $
d163 9
a171 6
    <command>LOCK TABLE</command> is useful only inside a transaction
    block (<command>BEGIN</>/<command>COMMIT</> pair), since the lock
    is dropped as soon as the transaction ends.  A <command>LOCK
    TABLE</> command appearing outside any transaction block forms a
    self-contained transaction, so the lock will be dropped as soon as
    it is obtained.
@


1.48
log
@Remove emacs info from footer of SGML files.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/lock.sgml,v 1.47 2005/04/28 21:47:10 tgl Exp $
d158 2
a159 1
    require <literal>UPDATE</> and/or <literal>DELETE</> privileges.
@


1.47
log
@Implement sharable row-level locks, and use them for foreign key references
to eliminate unnecessary deadlocks.  This commit adds SELECT ... FOR SHARE
paralleling SELECT ... FOR UPDATE.  The implementation uses a new SLRU
data structure (managed much like pg_subtrans) to represent multiple-
transaction-ID sets.  When more than one transaction is holding a shared
lock on a particular row, we create a MultiXactId representing that set
of transactions and store its ID in the row's XMAX.  This scheme allows
an effectively unlimited number of row locks, just as we did before,
while not costing any extra overhead except when a shared lock actually
has to be shared.   Still TODO: use the regular lock manager to control
the grant order when multiple backends are waiting for a row lock.

Alvaro Herrera and Tom Lane.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/lock.sgml,v 1.46 2005/01/22 23:22:19 momjian Exp $
a239 17

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"../reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:"/usr/lib/sgml/catalog"
sgml-local-ecat-files:nil
End:
-->
@


1.46
log
@More < and > changes to ampersands.

8.0.X and HEAD.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/lock.sgml,v 1.45 2005/01/04 00:39:53 tgl Exp $
d180 2
a181 2
   and the <xref linkend="sql-for-update"
   endterm="sql-for-update-title"> in the <command>SELECT</command>
@


1.45
log
@More minor updates and copy-editing.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/lock.sgml,v 1.44 2004/11/15 06:32:15 neilc Exp $
d213 2
a214 2
    (SELECT id FROM films WHERE rating < 5);
DELETE FROM films WHERE rating < 5;
@


1.45.4.1
log
@More < and > changes to ampersands.

8.0.X and HEAD.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/lock.sgml,v 1.45 2005/01/04 00:39:53 tgl Exp $
d213 2
a214 2
    (SELECT id FROM films WHERE rating &lt; 5);
DELETE FROM films WHERE rating &lt; 5;
@


1.44
log
@Replace "--" and "---" with "&mdash;" as appropriate, for better-looking
output.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/lock.sgml,v 1.43 2004/10/01 16:39:47 tgl Exp $
d53 1
a53 1
   isolation level read committed and needs to ensure that data in a
d69 8
a76 8
   To achieve a similar effect when running a transaction at the
   isolation level serializable, you have to execute the <command>LOCK
   TABLE</> statement before executing any data modification
   statement.  A serializable transaction's view of data will be
   frozen when its first data modification statement begins.  A later
   <command>LOCK TABLE</> will still prevent concurrent writes &mdash; but it
   won't ensure that what the transaction reads corresponds to the
   latest committed values.
d143 2
a144 2
      any conflicting locks to be released: if the specified lock
      cannot be immediately acquired without waiting, the transaction
d222 1
a222 1
	  
@


1.43
log
@Code review for NOWAIT patch: downgrade NOWAIT from fully reserved keyword
to unreserved keyword, use ereport not elog, assign a separate error code
for 'could not obtain lock' so that applications will be able to detect
that case cleanly.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql-server/doc/src/sgml/ref/lock.sgml,v 1.42 2004/03/12 00:52:23 neilc Exp $
d74 1
a74 1
   <command>LOCK TABLE</> will still prevent concurrent writes --- but it
d88 1
a88 1
   EXCLUSIVE</> mode when it holds <literal>SHARE</> mode --- but not
@


1.42
log
@Improve documentation for the newly-added NOWAIT clause of LOCK TABLE.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql-server/doc/src/sgml/ref/lock.sgml,v 1.41 2004/03/11 01:47:35 ishii Exp $
d40 1
a40 1
   cannot be immediately acquired, the transaction is aborted and an
@


1.41
log
@Add NOWAIT option to LOCK command
@
text
@d2 1
a2 1
$PostgreSQL: pgsql-server/doc/src/sgml/ref/lock.sgml,v 1.40 2003/12/14 00:05:29 neilc Exp $
d36 9
a44 7
   <command>LOCK TABLE</command> obtains a table-level lock, waiting if
   necessary for any conflicting locks to be released.
   If <literal>NOWAIT</literal> is given, <command>LOCK TABLE</command>
   does not wait for acquiring lock, and throws an error instead.
   Once obtained, the lock is held for the remainder of the current transaction.
   (There is no <command>UNLOCK TABLE</command> command; locks are always
   released at transaction end.)
d134 12
@


1.40
log
@This patch makes some SGML markup more consistent and makes a small
improvement to the SSL auth docs.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql-server/doc/src/sgml/ref/lock.sgml,v 1.39 2003/11/29 19:51:39 pgsql Exp $
d23 1
a23 1
LOCK [ TABLE ] <replaceable class="PARAMETER">name</replaceable> [, ...] [ IN <replaceable class="PARAMETER">lockmode</replaceable> MODE ]
d37 4
a40 2
   necessary for any conflicting locks to be released.  Once obtained,
   the lock is held for the remainder of the current transaction.
@


1.39
log
@
$Header: -> $PostgreSQL Changes ...
@
text
@d2 1
a2 1
$PostgreSQL: /cvsroot/pgsql-server/doc/src/sgml/ref/lock.sgml,v 1.38 2003/09/11 21:42:20 momjian Exp $
d111 4
a114 3
      The command <literal>LOCK a, b;</> is equivalent to
      <literal>LOCK a; LOCK b;</>. The tables are locked one-by-one in
      the order specified in the <command>LOCK</command> command.
d140 1
a140 1
    <literal>LOCK ... IN ACCESS SHARE MODE</> requires <literal>SELECT</>
d146 6
a151 5
    <command>LOCK</command> is useful only inside a transaction block
    (<command>BEGIN</>/<command>COMMIT</> pair), since the lock is dropped
    as soon as the transaction ends.  A <command>LOCK</> command appearing
    outside any transaction block forms a self-contained transaction, so the
    lock will be dropped as soon as it is obtained.
d162 5
a166 1
   about which modes conflict with which.
@


1.38
log
@This patch fixes a few missed GUC variables that were still upper case,
makes a few more small improvements to runtime.sgml, and makes some SGML
conventions more consistent.

Neil Conway
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql-server/doc/src/sgml/ref/lock.sgml,v 1.37 2003/09/09 18:28:53 tgl Exp $
@


1.37
log
@Remove a bunch of content-free Diagnostics sections, as per previous
discussion.  (Still have some work to do editing the remainder.)
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql-server/doc/src/sgml/ref/lock.sgml,v 1.36 2003/08/31 17:32:23 petere Exp $
d204 1
a204 1
   concurrency levels on transactions.  PostgreSQL supports that too;
@


1.36
log
@Add/edit index entries.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql-server/doc/src/sgml/ref/lock.sgml,v 1.35 2003/04/26 23:56:51 petere Exp $
a128 15
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </refsect1>

 <refsect1>
  <title>Diagnostics</title>

  <variablelist>
   <varlistentry>
    <term><computeroutput>LOCK TABLE</computeroutput></term>
    <listitem>
     <para>
      Message returned if the lock was successfully acquired.
@


1.35
log
@Editing of more reference pages.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql-server/doc/src/sgml/ref/lock.sgml,v 1.34 2002/09/21 18:32:54 petere Exp $
d16 4
@


1.35.2.1
log
@Update this branch to match CVS head, includes WIN32 improvements.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql-server/doc/src/sgml/ref/lock.sgml,v 1.36 2003/08/31 17:32:23 petere Exp $
a15 4

 <indexterm zone="sql-lock">
  <primary>LOCK</primary>
 </indexterm>
@


1.34
log
@Add more appropriate markup.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql-server/doc/src/sgml/ref/lock.sgml,v 1.33 2002/05/30 20:45:18 tgl Exp $
d11 1
d13 2
a14 6
  <refname>
   LOCK
  </refname>
  <refpurpose>
   explicitly lock a table
  </refpurpose>
d16 1
d18 2
a19 6
  <refsynopsisdivinfo>
   <date>2001-07-09</date>
  </refsynopsisdivinfo>
  <synopsis>
LOCK [ TABLE ] <replaceable class="PARAMETER">name</replaceable> [, ...]
LOCK [ TABLE ] <replaceable class="PARAMETER">name</replaceable> [, ...] IN <replaceable class="PARAMETER">lockmode</replaceable> MODE
d23 3
a25 218
	ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE |
	SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE
  </synopsis>

  <refsect2 id="R2-SQL-LOCK-1">
   <refsect2info>
    <date>1999-06-09</date>
   </refsect2info>

   <title>
    Inputs
   </title>
   <para>

    <variablelist>
     <varlistentry>
      <term><replaceable class="PARAMETER">name</replaceable></term>
      <listitem>
       <para>
	The name (optionally schema-qualified) of an existing table to lock.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>ACCESS SHARE MODE</term>
      <listitem>
       <para>
	This is the least restrictive lock mode.  It conflicts only with
	ACCESS EXCLUSIVE mode. It is used to protect a table from being
	modified by concurrent <command>ALTER TABLE</command>, 
	<command>DROP TABLE</command> and <command>VACUUM FULL</command>
	commands.
       </para>

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

     <varlistentry>
      <term>ROW SHARE MODE</term>
      <listitem>
       <para>
	Conflicts with EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
       </para>

       <note>
       <para>
	 The <command>SELECT FOR UPDATE</command> command acquires a
	 lock of this mode on the target table(s) (in addition to
	 <literal>ACCESS SHARE</literal> locks on any other tables
	 that are referenced but not selected <option>FOR UPDATE</option>).
	</para>
       </note>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>ROW EXCLUSIVE MODE</term>
      <listitem>
       <para>
	 Conflicts with SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE and
	 ACCESS EXCLUSIVE modes.
       </para>

       <note>
	<para>
	 The commands <command>UPDATE</command>,
	 <command>DELETE</command>, and <command>INSERT</command>
	 acquire this lock mode on the target table (in addition to
	 <literal>ACCESS SHARE</literal> locks on any other referenced
	 tables).  In general, this lock mode will be acquired by any
	 query that modifies the data in a table.
        </para>
       </note>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>SHARE UPDATE EXCLUSIVE MODE</term>
      <listitem>
       <para>
	Conflicts with SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE,
	EXCLUSIVE and
	ACCESS EXCLUSIVE modes. This mode protects a table against
	concurrent schema changes and <command>VACUUM</> runs.
       </para>

       <note>
       <para>
	 Acquired by <command>VACUUM</command> (without
	 <option>FULL</option>).
       </para>
       </note>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>SHARE MODE</term>
      <listitem>
       <para>
	Conflicts with ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE,
	SHARE ROW EXCLUSIVE, EXCLUSIVE and
	ACCESS EXCLUSIVE modes. This mode protects a table against
	concurrent data changes.
       </para>

       <note>
       <para>
	 Acquired by <command>CREATE INDEX</command>.
       </para>
       </note>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>SHARE ROW EXCLUSIVE MODE</term>
      <listitem>
       <para>
        Conflicts with ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE,
	SHARE ROW EXCLUSIVE, EXCLUSIVE and ACCESS EXCLUSIVE modes.
       </para>

       <note>
       <para>
         This lock mode is not automatically acquired by any
         <productname>PostgreSQL</productname> command.
       </para>
       </note>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>EXCLUSIVE MODE</term>
      <listitem>
       <para>
	Conflicts with ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE,
	SHARE, SHARE ROW EXCLUSIVE,
	EXCLUSIVE and ACCESS EXCLUSIVE modes.
	This mode allows only concurrent ACCESS SHARE, i.e., only reads
	from the table can proceed in parallel with a transaction holding
	this lock mode.
       </para>

       <note>
       <para>
        This lock mode is not automatically acquired by any
        <productname>PostgreSQL</productname> command.
       </para>
       </note>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>ACCESS EXCLUSIVE MODE</term>
      <listitem>
       <para>
	Conflicts with all lock modes.  This mode guarantees that the
	holder is the only transaction accessing the table in any way.
       </para>

       <note>
	<para>
	 Acquired by <command>ALTER TABLE</command>,
	 <command>DROP TABLE</command>, and <command>VACUUM FULL</command>
	 statements.
	 This is also the default lock mode for <command>LOCK TABLE</command>
         statements that do not specify a mode explicitly.
	</para>
       </note>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>
  </refsect2>

  <refsect2 id="R2-SQL-LOCK-2">
   <refsect2info>
    <date>1998-09-24</date>
   </refsect2info>
   <title>
    Outputs
   </title>
   <para>
    
    <variablelist>
     <varlistentry>
      <term><computeroutput>
LOCK TABLE
       </computeroutput></term>
      <listitem>
       <para>
	The lock was successfully acquired.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><computeroutput>
ERROR <replaceable class="PARAMETER">name</replaceable>: Table does not exist.
       </computeroutput></term>
      <listitem>
       <para>
	Message returned if <replaceable class="PARAMETER">name</replaceable>
	does not exist.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>
  </refsect2>
d28 2
a29 7
 <refsect1 id="R1-SQL-LOCK-1">
  <refsect1info>
   <date>1998-09-24</date>
  </refsect1info>
  <title>
   Description
  </title>
d40 3
a42 3
   When acquiring locks automatically for commands that reference tables,
   <productname>PostgreSQL</productname> always uses the least restrictive
   lock mode possible. <command>LOCK TABLE</command> 
d44 14
d61 8
a68 27
   For example, suppose an application runs a transaction at 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 SHARE 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 SHARE lock mode conflicts with the ROW
   EXCLUSIVE lock acquired by writers, and your
   <command>LOCK TABLE <replaceable class="PARAMETER">name</replaceable> IN SHARE MODE</command>
   statement will wait until any concurrent holders of ROW EXCLUSIVE mode
   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.

   <note>
    <para>
     To achieve a similar effect when running a transaction
     at the SERIALIZABLE isolation level, you have to execute the
     <command>LOCK TABLE</>
     statement before executing any <acronym>DML</> statement.  A serializable
     transaction's view of data will be frozen when its first <acronym>DML</> statement
     begins.  A later <command>LOCK</> will still prevent concurrent writes
     --- but it
     won't ensure that what the transaction reads corresponds to the latest
     committed values.
    </para>
   </note>
d72 14
a85 9
   If a transaction of this sort is going to
   change the data in the table, then it should use SHARE ROW EXCLUSIVE lock
   mode instead of SHARE 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 SHARE mode, and then be unable to also
   acquire ROW EXCLUSIVE mode to actually perform their updates.  (Note that
   a transaction's own locks never conflict, so a transaction can acquire
   ROW EXCLUSIVE mode when it holds SHARE mode --- but not if anyone else
   holds SHARE mode.)
d87 1
a87 1
  
d89 2
a90 1
   Two general rules may be followed to prevent deadlock conditions:
d92 1
d94 2
a95 25
  <itemizedlist>  
   <listitem>
    <para>
     Transactions have to acquire locks on the same objects in the same order.
    </para>
   
    <para>
     For example, if one application updates row R1 and than updates 
     row R2 (in the same transaction) then the second application shouldn't 
     update row R2 if it's going to update row R1 later (in a single transaction). 
     Instead, it should update rows R1 and R2 in the same order as the first 
     application.
    </para>
   </listitem>

   <listitem>
    <para>
     If multiple lock modes are involved for a single object,
     then transactions should always acquire the  most restrictive mode first.
    </para>
   
    <para>
     An example for this rule was given previously when discussing the 
     use of SHARE ROW EXCLUSIVE mode rather than SHARE mode.
    </para>
d97 33
a129 2
   </listitem>
  </itemizedlist>
d131 2
a132 7
  <para>
   <productname>PostgreSQL</productname> does detect deadlocks and will
   rollback at least one waiting transaction to resolve the deadlock.
   If it is not practical to code an application to follow the above rules
   strictly, an alternative solution is to be prepared to retry transactions
   when they are aborted by deadlocks.
  </para>
d134 11
a144 6
  <para>
   When locking multiple tables, the command <literal>LOCK a, b;</> is
   equivalent to <literal>LOCK a; LOCK b;</>. The tables are locked one-by-one
   in the order specified in the
   <command>LOCK</command> command.
  </para>
d146 2
a147 7
  <refsect2 id="R2-SQL-LOCK-3">
   <refsect2info>
    <date>1999-06-08</date>
   </refsect2info>
   <title>
    Notes
   </title>
d157 1
a157 1
    (<command>BEGIN</>...<command>COMMIT</>), since the lock is dropped
d164 8
a171 53
   <acronym>RDBMS</acronym> locking uses the following standard terminology:

   <variablelist>
    <varlistentry>
     <term>EXCLUSIVE</term>
     <listitem>
      <para>
       An exclusive lock prevents other locks of the same type from being
       granted.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term>SHARE</term>
     <listitem>
      <para>
      A shared lock allows others to also hold the same type of lock,
      but prevents the corresponding EXCLUSIVE lock from being granted.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term>ACCESS</term>
     <listitem>
      <para>
       Locks table schema.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term>ROW</term>
     <listitem>
      <para>
       Locks individual rows.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

  <para>
   <productname>PostgreSQL</productname> does not follow this terminology
   exactly.  <command>LOCK TABLE</> only deals with table-level locks, and
   so the mode names involving ROW 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,
   ROW EXCLUSIVE mode does not follow this naming convention accurately,
   since it is a sharable table lock.  Keep in mind that all the lock modes
   have identical semantics so far as <command>LOCK TABLE</> is concerned,
   differing only in the rules about which modes conflict with which.
a172 2

  </refsect2>
d175 2
a176 4
 <refsect1 id="R1-SQL-LOCK-2">
  <title>
   Usage
  </title>
d179 1
a179 1
   Obtain a SHARE lock on a primary key table when going to perform
d182 1
a182 1
  <programlisting>
d191 1
a191 1
   </programlisting>
d195 1
a195 1
   Take a SHARE ROW EXCLUSIVE lock on a primary key table when going to perform
d198 1
a198 1
   <programlisting>
d205 1
a205 1
   </programlisting>
d209 2
a210 4
 <refsect1 id="R1-SQL-LOCK-3">
  <title>
   Compatibility
  </title>
d212 7
a218 13
  <refsect2 id="R2-SQL-LOCK-4">
   <refsect2info>
    <date>1998-09-24</date>
   </refsect2info>
   <title>
    SQL92
   </title>
   <para>
    There is no <command>LOCK TABLE</command> in <acronym>SQL92</acronym>,
    which instead uses <command>SET TRANSACTION</command> to specify
    concurrency levels on transactions.  We support that too; see
    <xref linkend="SQL-SET-TRANSACTION" endterm="SQL-SET-TRANSACTION-TITLE"> for details.
   </para>
d220 7
a226 7
   <para>
    Except for ACCESS SHARE, ACCESS EXCLUSIVE, and SHARE UPDATE EXCLUSIVE lock
    modes, the <productname>PostgreSQL</productname> lock modes and the
    <command>LOCK TABLE</command> syntax are compatible with those
    present in <productname>Oracle</productname>(TM).
   </para>
  </refsect2>
@


1.33
log
@Improve manual's discussion of locking and MVCC.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.32 2002/04/23 02:07:16 tgl Exp $
d121 1
a121 1
	concurrent schema changes and VACUUMs.
d292 2
a293 2
     statement before executing any DML statement.  A serializable
     transaction's view of data will be frozen when its first DML statement
@


1.32
log
@Update SQL-command reference pages for schema features.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.31 2002/04/21 19:02:39 thomas Exp $
a55 6
       <note>
	<para>
	 This lock mode is acquired automatically over tables being queried.
	</para>
       </note>

d63 9
d78 4
d84 4
a87 1
	 Automatically acquired by <command>SELECT ... FOR UPDATE</command>.
a89 4

       <para>
	Conflicts with EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
       </para>
d96 5
d103 1
a103 1
	 Automatically acquired by <command>UPDATE</command>, 
d105 4
a108 1
	 statements.
a110 5

       <para>
	 Conflicts with SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE and
	 ACCESS EXCLUSIVE modes.
       </para>
a116 7
       <note>
       <para>
	 Automatically acquired by <command>VACUUM</command> (without
	 <option>FULL</option>).
       </para>
       </note>

d123 7
a135 1
       <note>
d137 4
a140 2
	 Automatically acquired by <command>CREATE INDEX</command>.
	 Share-locks the entire table.
a141 1
       </note>
d143 1
d145 1
a145 4
	Conflicts with ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE,
	SHARE ROW EXCLUSIVE, EXCLUSIVE and
	ACCESS EXCLUSIVE modes. This mode protects a table against
	concurrent data updates.
d147 1
a153 1
       <note>
d155 2
a156 2
	This is like EXCLUSIVE MODE, but allows ROW SHARE locks
        by others.
a157 1
       </note>
d159 1
d161 2
a162 2
        Conflicts with ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE,
	SHARE ROW EXCLUSIVE, EXCLUSIVE and ACCESS EXCLUSIVE modes.
d164 1
a170 8

       <note>
       <para>
	This mode is yet more restrictive than SHARE ROW EXCLUSIVE.  
	It blocks all concurrent ROW SHARE/SELECT...FOR UPDATE queries.
       </para>
       </note>

d179 7
d192 5
d199 2
a200 2
	 Automatically acquired by <command>ALTER TABLE</command>,
	 <command>DROP TABLE</command>, <command>VACUUM FULL</command>
d202 2
a203 2
	 This is the most restrictive lock mode which
	 protects a locked table from any concurrent operations.
a205 12

       <note>
	<para>
	 This lock mode is also acquired by an unqualified
	 <command>LOCK TABLE</command> (i.e., the command without an explicit
	 lock mode option).
	</para>
       </note>

       <para>
	Conflicts with all lock modes.
       </para>
d258 5
a262 5
   <command>LOCK TABLE</command> controls concurrent access to a table
   for the duration of a transaction.
   <productname>PostgreSQL</productname> always uses the least restrictive
   lock mode whenever possible. <command>LOCK TABLE</command> 
   provides for cases when you might need more restrictive locking.
d266 4
a269 44
   <acronym>RDBMS</acronym> locking uses the following terminology:

   <variablelist>
    <varlistentry>
     <term>EXCLUSIVE</term>
     <listitem>
      <para>
       An exclusive lock prevents other locks of the same type from being
       granted.  (Note: ROW EXCLUSIVE mode does not follow this naming
       convention perfectly, since it is shared at the level of the table;
       it is exclusive only with respect to specific rows that are being
       updated.)
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term>SHARE</term>
     <listitem>
      <para>
      A shared lock allows others to also hold the same type of lock,
      but prevents the corresponding EXCLUSIVE lock from being granted.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term>ACCESS</term>
     <listitem>
      <para>
       Locks table schema.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term>ROW</term>
     <listitem>
      <para>
       Locks individual rows.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
d274 2
a275 2
   isolation level and needs to ensure the existence of data in a table for
   the duration of the
d277 3
a279 3
   table before querying. This will prevent concurrent data changes 
   and ensure further read operations over the table see data in their 
   actual current state, because SHARE lock mode conflicts with any ROW
d282 4
a285 3
   statement will wait until any concurrent write operations commit or
   rollback. Thus, once you obtain the lock, there are no uncommitted
   writes outstanding.
d289 3
a291 2
     To read data in their actual current state when running a transaction
     at the SERIALIZABLE isolation level, you have to execute the LOCK TABLE
d294 4
a297 1
     begins.
d303 9
a311 6
   In addition to the requirements above, if a transaction is going to
   change data in a table, then SHARE ROW EXCLUSIVE lock mode should
   be acquired to prevent deadlock conditions when two concurrent
   transactions attempt to lock the table in SHARE mode and then
   try to change data in this table, both (implicitly) acquiring 
   ROW EXCLUSIVE lock mode that conflicts with a concurrent SHARE lock.
d315 1
a315 3
   To continue with the deadlock (when two transactions wait for one another)
   issue raised above, you should follow two general rules to prevent 
   deadlock conditions:
d335 1
a335 3
     Transactions should acquire two conflicting lock modes only if
     one of them is self-conflicting (i.e., may be held by only one
     transaction at a time). If multiple lock modes are involved,
d347 7
a353 6
  <note>
   <para>
    <productname>PostgreSQL</productname> does detect deadlocks and will
    rollback at least one waiting transaction to resolve the deadlock. 
   </para>
  </note>
d356 3
a358 2
   When locking multiple tables, the command LOCK a, b; is equivalent to LOCK
   a; LOCK b;. The tables are locked one-by-one in the order specified in the
d384 56
d449 1
a449 1
   Illustrate a SHARE lock on a primary key table when going to perform
@


1.31
log
@Augment the date/time examples in the User's Guide to reflect the newer
 capabilities of specifying time zones as intervals per SQL9x.
Put refentrytitle contents on the same line as the tag.
 Otherwise, leading whitespace is propagated into the product, which
 (at least) messes up the ToC layout.
Remove (some) docinfo tags containing dates. Best to omit if the dates
 are not accurate; maybe use CVS dates instead or leave them out.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.30 2002/01/18 01:05:43 tgl Exp $
d48 1
a48 1
	The name of an existing table to lock.
@


1.30
log
@Explain privileges required for LOCK.  Minor wordsmithing too.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.29 2001/12/08 03:24:37 thomas Exp $
d8 1
a8 3
  <refentrytitle id="sql-lock-title">
   LOCK
  </refentrytitle>
@


1.29
log
@Use PostgreSQL consistantly throughout docs. Before, usage was split evenly
 between Postgres and PostgreSQL.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.28 2001/09/03 12:57:50 petere Exp $
d79 1
a79 2
	 Automatically acquired by <command>SELECT...FOR UPDATE</command>.
	 While it is a shared lock, may be upgraded later to a ROW EXCLUSIVE lock.
d177 3
d230 1
a230 1
	The lock was successfully applied.
d315 8
a322 8
   For example, an application runs a transaction at READ COMMITTED isolation
   level and needs to ensure the existence of data in a table for the
   duration of the
   transaction. To achieve this you could use SHARE lock mode over the
   table before querying. This will protect data from concurrent changes 
   and provide any further read operations over the table with data in their 
   actual current state, because SHARE lock mode conflicts with any ROW EXCLUSIVE 
   one acquired by writers, and your
d324 3
a326 1
   statement will wait until any concurrent write operations commit or rollback.
d330 5
a334 4
     To read data in their real current state when running a transaction
     at the SERIALIZABLE isolation level you have to execute a LOCK TABLE
     statement before executing any DML statement, when the transaction defines
     what concurrent changes will be visible to itself.
d349 1
a349 1
   To continue with the deadlock (when two transaction wait for one another)
d372 2
a373 2
     one of them is self-conflicting (i.e., may be held by one
     transaction at time only). If multiple lock modes are involved,
d407 3
a409 2
    <command>LOCK</command> is a <productname>PostgreSQL</productname>
    language extension.
d413 5
a417 8
    Except for ACCESS SHARE, ACCESS EXCLUSIVE, and SHARE UPDATE EXCLUSIVE lock
    modes, the <productname>PostgreSQL</productname> lock modes and the
    <command>LOCK TABLE</command> syntax are compatible with those
    present in <productname>Oracle</productname>.
   </para>

   <para>
    <command>LOCK</command> works only inside transactions.
d476 7
@


1.28
log
@Put some kind of grammatical uniformity in the <refpurpose> lines.
@
text
@d2 2
a3 2
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.27 2001/08/10 14:30:14 momjian Exp $
Postgres documentation
d260 1
a260 1
   <productname>Postgres</productname> always uses the least restrictive
d382 1
a382 1
    <productname>Postgres</productname> does detect deadlocks and will
d402 1
a402 1
    <command>LOCK</command> is a <productname>Postgres</productname>
d408 1
a408 1
    modes, the <productname>Postgres</productname> lock modes and the
@


1.27
log
@Patch to LOCK multiple tables in one LOCK command.

Neil Padgett
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.26 2001/08/04 22:01:38 momjian Exp $
d18 1
a18 1
   Explicitly lock a table / tables inside a transaction
@


1.26
log
@Back out LOCK A,B,C patch at Tom's suggestion.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.25 2001/08/04 19:38:59 momjian Exp $
d18 1
a18 1
   Explicitly lock a table inside a transaction
d26 2
a27 2
LOCK [ TABLE ] <replaceable class="PARAMETER">name</replaceable>
LOCK [ TABLE ] <replaceable class="PARAMETER">name</replaceable> IN <replaceable class="PARAMETER">lockmode</replaceable> MODE
d376 1
d387 6
d416 1
@


1.25
log
@Add LOCK A,B,C functionality as LOCK A;LOCK B;LOCK C; as agreed.

Neil Padgett
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.24 2001/07/09 22:18:33 tgl Exp $
d18 1
a18 1
   Explicitly lock a table / tables inside a transaction
d26 2
a27 2
LOCK [ TABLE ] <replaceable class="PARAMETER">name</replaceable> [,...]
LOCK [ TABLE ] <replaceable class="PARAMETER">name</replaceable> [,...] IN <replaceable class="PARAMETER">lockmode</replaceable> MODE
a375 1

a385 6
  <para>
   When locking multiple tables, the command LOCK a, b; is equivalent to LOCK
   a; LOCK b;. The tables are locked one-by-one in the order specified in the
   <command>LOCK</command> command.
  </para>

a408 1

@


1.24
log
@Add SHARE UPDATE EXCLUSIVE lock mode, coming soon to a VACUUM near you.
Name chosen per pghackers discussion around 6/22/01.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.23 2000/12/25 23:15:26 petere Exp $
d18 1
a18 1
   Explicitly lock a table inside a transaction
d26 2
a27 2
LOCK [ TABLE ] <replaceable class="PARAMETER">name</replaceable>
LOCK [ TABLE ] <replaceable class="PARAMETER">name</replaceable> IN <replaceable class="PARAMETER">lockmode</replaceable> MODE
d376 1
d387 6
d416 1
@


1.23
log
@Refine some things to create better looking man pages.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.22 2000/10/05 19:48:18 momjian Exp $
d23 1
a23 1
   <date>1999-07-20</date>
d27 6
a32 2
LOCK [ TABLE ] <replaceable class="PARAMETER">name</replaceable> IN [ ROW | ACCESS ] { SHARE | EXCLUSIVE } MODE
LOCK [ TABLE ] <replaceable class="PARAMETER">name</replaceable> IN SHARE ROW EXCLUSIVE MODE
a39 1

d68 1
a68 1
	<command>DROP TABLE</command> and <command>VACUUM</command> 
d109 19
d138 2
a139 1
	Conflicts with ROW EXCLUSIVE, SHARE ROW EXCLUSIVE, EXCLUSIVE and
d141 1
a141 1
	concurrent updates.
d151 1
a151 1
	This is like EXCLUSIVE MODE, but allows SHARE ROW locks
d157 2
a158 2
        Conflicts with ROW EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE,
	EXCLUSIVE and ACCESS EXCLUSIVE modes.
d175 2
a176 1
	Conflicts with ROW SHARE, ROW EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE,
d188 4
a191 3
	 <command>DROP TABLE</command>, <command>VACUUM</command> statements.
	 This is the most restrictive lock mode which conflicts with all other
	 lock modes and protects a locked table from any concurrent operations.
d202 4
d273 5
a277 1
       Exclusive lock that prevents other locks from being granted.
d286 2
a287 1
       Allows others to share lock.  Prevents EXCLUSIVE locks.
a309 7

   <note>
    <para>
     If EXCLUSIVE or SHARE are not specified, EXCLUSIVE is assumed.
     Locks exist for the duration of the transaction.
    </para>
   </note>
d400 2
a401 2
    Except for ACCESS SHARE/EXCLUSIVE lock modes, all other
    <productname>Postgres</productname> lock modes and the
@


1.22
log
@Add proofreader's changes to docs.
Fix misspelling of disbursion to dispersion.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.21 2000/07/22 04:30:27 momjian Exp $
d437 1
a437 1
    <xref linkend="SQL-SET-TITLE" endterm="SQL-SET-TITLE"> for details.
@


1.21
log
@spell cleanups
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.20 2000/03/28 14:35:27 thomas Exp $
d77 1
a77 1
	 While it is a shared lock, may be upgrade later to a ROW EXCLUSIVE lock.
d173 1
a173 1
	 <command>LOCK TABLE</command> (i.e. the command without an explicit
d233 1
a233 1
   provided for cases when you might need more restrictive locking.
d301 1
a301 1
     statement before execution any DML statement, when the transaction defines
d309 1
a309 1
   change data in a table then SHARE ROW EXCLUSIVE lock mode should
d313 1
a313 1
   ROW EXCLUSIVE lock mode that conflicts with concurrent SHARE lock.
d317 1
a317 1
   To continue with the deadlock (when two transaction wait one another)
d340 1
a340 1
     one of them is self-conflicting (i.e. may be held by one
@


1.20
log
@Fix markup for terminology.
@
text
@d2 1
a2 1
$Header: /home/cvs/pgsql/doc/src/sgml/ref/lock.sgml,v 1.19 2000/03/24 03:57:06 momjian Exp $
d287 1
a287 1
   level and needs to ensure the existance of data in a table for the
@


1.19
log
@Move LOCK terms down.
@
text
@d2 1
a2 1
$Header: /usr/local/cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.18 2000/03/24 01:20:09 momjian Exp $
a226 61
   <title>
    Terms
   </title>
   <para>
    <variablelist>
     <varlistentry>
      <term>EXCLUSIVE</term>
      <listitem>
       <para>
	Exclusive lock that prevents other locks from being granted.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

    <variablelist>
     <varlistentry>
      <term>SHARE</term>
      <listitem>
       <para>
	Allows others to share lock.  Prevents EXCLUSIVE locks.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

    <variablelist>
     <varlistentry>
      <term>ACCESS</term>
      <listitem>
       <para>
	Locks table schema.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

    <variablelist>
     <varlistentry>
      <term>ROW</term>
      <listitem>
       <para>
	Locks individual rows.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

    <variablelist>
     <varlistentry>
      <term>Notes</term>
      <listitem>
       <para>
	If EXCLUSIVE or SHARE are not specified, EXCLUSIVE is assumed.
	Locks exist for the duration of the transaction.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

   </para>
d229 2
d234 49
@


1.18
log
@Update HISTORY
@
text
@d2 1
a2 1
$Header: /usr/local/cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.17 2000/03/23 23:16:47 momjian Exp $
a35 61
   <title>
    Terms
   </title>
   <para>
    <variablelist>
     <varlistentry>
      <term>EXCLUSIVE</term>
      <listitem>
       <para>
	Exclusive lock that prevents other locks from being granted.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

    <variablelist>
     <varlistentry>
      <term>SHARE</term>
      <listitem>
       <para>
	Allows others to share lock.  Prevents EXCLUSIVE locks.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

    <variablelist>
     <varlistentry>
      <term>ACCESS</term>
      <listitem>
       <para>
	Locks table schema.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

    <variablelist>
     <varlistentry>
      <term>ROW</term>
      <listitem>
       <para>
	Locks individual rows.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

    <variablelist>
     <varlistentry>
      <term>Notes</term>
      <listitem>
       <para>
	If EXCLUSIVE or SHARE are not specified, EXCLUSIVE is assumed.
	Locks exist for the duration of the transaction.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

   </para>
d227 62
@


1.17
log
@>> 5. empty define that results in an empty but terminated line ( ; )
easy (maybe dumb) fix for 5 in attachment define.patch

greetings, Andreas
@
text
@d2 1
a2 1
$Header: /usr/local/cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.16 2000/03/23 22:25:35 momjian Exp $
d90 1
a90 2
	If  ROW or ACCESS is not specified, the entire table is locked
	for the duration of the transaction.
a118 2
	 It is released after the statement completes.
	 It does not remain for the duration of the transaction.
d124 1
a124 1
	ACCESS EXCLUSIVE mode. It is used to protect a table being
d138 1
a138 2
	 While it is a shared lock, there is the intention to later upgrade
	 this to a ROW EXCLUSIVE lock.
@


1.16
log
@Back out // compiler flag.
@
text
@d2 1
a2 1
$Header: /usr/local/cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.14 1999/10/01 15:26:29 thomas Exp $
d89 1
a89 1
	If EXCLUSIVE or SHARE are not speicified, EXCLUSIVE is assumed.
d120 1
a120 1
	 This lock is released automatically after the statement completes.
d127 1
a127 1
	ACCESS EXCLUSIVE mode. It is intended to protect a table being
d142 1
a142 1
	 this to an EXCLUSIVE lock.
@


1.15
log
@Hmm, absolute pathnames for the copy makes sense. I'll whip up that
patch in a second. Should be sufficent to just make sure the first
character is a '/', right?

Ross J. Reedstrom
@
text
@d126 1
a126 1
	This is the least restrictive lock mode which conflicts only with 
d140 2
a141 2
	 Automatically acquired by any <command>SELECT FOR UPDATE</command> statement.
	 While it is a SHARE lock, there is the intention to later upgrade
d157 3
a159 2
	 Automatically acquired by any <command>UPDATE</command>, 
	 <command>DELETE</command>, <command>INSERT</command> statement.
d165 1
a165 2
	 ACCESS EXCLUSIVE modes. Generally means that a transaction
	 updated or inserted some tuples in a table.
d175 2
a176 2
	 Automatically acquired by any <command>CREATE INDEX</command> statement.
	 Share-locks entire table.
d191 6
a198 2
	This is like an EXCLUSIVE lock, but allows SHARE ROW locks
        by others.
d209 7
d218 1
a218 3
	EXCLUSIVE and ACCESS EXCLUSIVE modes. This mode is yet more
	restrictive than that of SHARE ROW EXCLUSIVE; it blocks all concurrent
	SHARE ROW/SELECT FOR UPDATE queries.
d230 2
a234 5
       <para>
	This is the most restrictive lock mode which conflicts with all other
	lock modes and protects a locked table from any concurrent operations.
       </para>
	   
@


1.14
log
@Refer to "name", rather than "table" as the replaceable parameter.
 Seems to read better this way...
@
text
@d2 1
a2 1
$Header: /home/cvs/pgsql/doc/src/sgml/ref/lock.sgml,v 1.13 1999/07/22 15:09:12 thomas Exp $
d35 64
d120 2
a121 2
	 <productname>Postgres</productname> releases automatically acquired
	 ACCESS SHARE locks after the statement is done.
d128 1
a128 1
	queried from concurrent <command>ALTER TABLE</command>, 
d130 1
a130 1
	statements over the same table.
d141 2
d159 1
a159 1
	</para>
d176 1
d193 4
a196 4
	Conflicts with ROW EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE,
	EXCLUSIVE and ACCESS EXCLUSIVE modes. This mode is more
	restrictive than SHARE mode because of only one transaction
	at time can hold this lock.
d209 1
a209 1
	SELECT FOR UPDATE queries.
d219 1
a219 1
	 Automatically acquired by <command>ALTER TABLE</command>, 
@


1.13
log
@Complete merge of all old man page information.
ecpg reference page still needs formatting.
@
text
@d2 1
a2 1
$Header$
d18 1
a18 1
   Explicit lock of a table inside a transaction
d26 3
a28 3
LOCK [ TABLE ] <replaceable class="PARAMETER">table</replaceable>
LOCK [ TABLE ] <replaceable class="PARAMETER">table</replaceable> IN [ ROW | ACCESS ] { SHARE | EXCLUSIVE } MODE
LOCK [ TABLE ] <replaceable class="PARAMETER">table</replaceable> IN SHARE ROW EXCLUSIVE MODE
d42 1
a42 1
      <term><replaceable class="PARAMETER">table</replaceable></term>
d198 1
a198 1
ERROR <replaceable class="PARAMETER">table</replaceable>: Table does not exist.
d202 1
a202 1
	Message returned if <replaceable class="PARAMETER">table</replaceable>
d233 3
a235 2
   one acquired by writers, and your LOCK TABLE table IN SHARE MODE statement 
   will wait until any concurrent write operations commit or rollback.
@


1.12
log
@Fix markup for docbook2man man page generation.
No big deal; fixed lots of other markup at the same time.
Bigest change: make sure there is no whitespace
 in front of <term> contents.
This will probably help the other output types too.
@
text
@d1 5
d8 1
a8 1
  <refentrytitle>
d23 1
a23 1
   <date>1998-09-24</date>
a363 2
  <para>
  </para>
d375 1
a375 1
    concurrency level on transactions.  We support that too; see
@


1.11
log
@Make minor changes in wording.
Adjust tags to get a clean build.
@
text
@d37 1
a37 3
      <term>
       <replaceable class="PARAMETER">table</replaceable>
      </term>
d46 1
a46 3
      <term>
       ACCESS SHARE MODE
      </term>
d49 6
a54 6
       <para>
	This lock mode is acquired automatically over tables being queried.
	<productname>Postgres</productname> releases automatically acquired
	ACCESS SHARE locks after the statement is done.
	   </para>
	   </note>
d67 1
a67 3
      <term>
       ROW SHARE MODE
      </term>
d82 1
a82 3
      <term>
       ROW EXCLUSIVE MODE
      </term>
d85 1
a85 1
       <para>
d100 1
a100 3
      <term>
       SHARE MODE
      </term>
d117 1
a117 3
      <term>
       SHARE ROW EXCLUSIVE MODE
      </term>
d130 1
a130 3
      <term>
       EXCLUSIVE MODE
      </term>
d143 1
a143 3
      <term>
       ACCESS EXCLUSIVE MODE
      </term>
a165 1

d181 14
a194 3
      <term>
       ERROR <replaceable class="PARAMETER">table</replaceable>: Table does not exist.
      </term>
d325 3
d329 9
a337 15
    --
    -- SHARE lock primary key table when going to perform
    -- insert into foreign key table.
    --
    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;
  </programlisting>
d341 11
a351 12
  <programlisting>
    --
    -- SHARE ROW EXCLUSIVE lock primary key table when going to perform
    -- delete operation.
    --
    BEGIN WORK;
    LOCK TABLE films IN SHARE ROW EXCLUSIVE MODE;
    DELETE FROM films_user_comments WHERE id IN
      (SELECT id FROM films WHERE rating < 5);
    DELETE FROM films WHERE rating < 5;
    COMMIT WORK;
  </programlisting>
a352 1
	
d359 2
d391 1
a391 1
sgml-local-catalogs:"/usr/lib/sgml/CATALOG"
@


1.10
log
@MVCC updation.
@
text
@d56 1
a56 1
	ACCESS SHARE locks after statement is done.
d60 3
a62 3
	   <para>
	This is the less restrictive lock mode which conflicts with 
	ACCESS EXCLUSIVE mode only. It's intended to protect table being
d77 2
a78 2
	 Automatically acquired by <command>SELECT FOR UPDATE</command> statement.
	   </para>
d81 2
a82 2
	   <para>
	 Conflicts with EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
d94 4
a97 4
	 Automatically acquired by <command>UPDATE</command>, 
	 <command>DELETE</command>, <command>INSERT</command> statements.
	   </para>
	   </note>
d99 1
a99 1
	   <para>
d102 1
a102 1
	 updated/inserted some tuples in a table.
d114 1
a114 1
	 Automatically acquired by <command>CREATE INDEX</command> statement.
d118 4
a121 4
	   <para>
	 Conflicts with ROW EXCLUSIVE, SHARE ROW EXCLUSIVE, EXCLUSIVE and
	 ACCESS EXCLUSIVE modes. This mode protects a table against
	 concurrent updates.
d132 1
a132 1
	   <para>
d147 1
a147 1
	   <para>
d150 1
a150 1
	restrictive than SHARE ROW EXCLUSIVE one - it blocks concurrent
d162 6
a168 6
	Automatically acquired by <command>ALTER TABLE</command>, 
	<command>DROP TABLE</command>, <command>VACUUM</command> statements.
	   </para>
	   </note>

	   <para>
d170 2
a171 2
	lock modes and protects locked table from any concurrent operations.
	   </para>
d173 7
a179 7
	   <note>
	   <para>
	This lock mode is also acquired by first form of
	<command>LOCK TABLE</command> (i.e. without explicit
	lock mode option).
	   </para>
	   </note>
d221 3
a223 3
   <productname>Postgres</productname> always uses less restrictive
   lock modes ever possible. <command>LOCK TABLE</command> statement 
   provided for cases when you might need in more restrictive locking.
d227 4
a230 3
   For example, application run transaction at READ COMMITTED isolation
   level and need to ensure existance data in a table for duration of
   transaction. To achieve this you could use SHARE lock mode over
d232 13
a244 8
   and provide your further read operations over table with data in their 
   real current state, because of SHARE lock mode conflicts with ROW EXCLUSIVE 
   one, acquired by writers, and your LOCK TABLE table IN SHARE MODE statement 
   will wait untill concurrent write operations (if any) commit/rollback.
   (Note that to read data in their real current state running transaction
   at SERIALIZABLE isolation level you have to execute LOCK TABLE
   statement before execution any DML statement, when transaction defines
   what concurrent changes will be visible to herself).
d248 1
a248 1
   If, in addition to requirements above, transaction is going to
d251 1
a251 1
   transactions would lock table in SHARE mode and than would
d257 2
a258 2
   Following deadlock issue (when two transaction wait one another)
   touched above, you should follow two general rules to prevent 
d261 6
a266 5
  
  <listitem>
   <para>
    Transactions have to acquire locks on the same objects in the same order.
   </para>
d268 16
a283 16
   <para>
    For example, if one application updates row R1 and than updates 
    row R2 (in the same transaction) then second application shouldn't 
    update row R2 if it's going update row R1 later (in single transaction). 
    Instead, it should update R1 and R2 rows in the same order as first 
    application.
   </para>
  </listitem>

  <listitem>
   <para>
    Transactions should acquire two conflicting lock modes only if
    one of them is self-conflicting (i.e. may be held by one
    transaction at time only) and should acquire most restrictive
    mode first.
   </para>
d285 6
a290 5
   <para>
    Example for this rule is described above when told about using
    SHARE ROW EXCLUSIVE mode instead of SHARE one.
   </para>
  </listitem>
d295 1
a295 1
    rollback one of waiting transactions to resolve the deadlock. 
d301 1
a301 1
    <date>1998-09-24</date>
d306 1
d311 1
d314 5
a318 3
    <productname>Postgres</productname> lock modes and 
    <command>LOCK TABLE</command> syntax are compatible with
    <productname>Oracle</productname> ones.
d344 1
a344 1
      (_id_, 'GREAT! I was waiting it so long!');
d381 2
a382 1
    concurrency level on transactions.  We support that too.
@


1.9
log
@Add input parameters for LOCK TABLE. Still needs explanation from Vadim.
Fix markup.
@
text
@d28 1
a28 1
    <date>1998-09-01</date>
d49 1
a49 1
       SHARE MODE
d52 1
d54 12
d72 1
a72 1
       EXCLUSIVE MODE
d75 1
d77 6
d89 1
a89 1
       ROW SHARE MODE
d92 1
d94 9
d109 1
a109 1
       ROW EXCLUSIVE MODE
d112 1
d114 8
d128 1
a128 1
       ACCESS SHARE MODE
d131 6
a136 1
       <para>
d143 1
a143 1
       ACCESS EXCLUSIVE MODE
d146 6
a151 1
       <para>
d158 1
a158 1
       SHARE ROW EXCLUSIVE MODE
d161 1
d163 17
a179 1
       </para>
d182 1
d221 27
a247 24
   By default, <command>LOCK</command> locks in exclusive mode a table inside
   a transaction. Various options allow shared access, or row-level locking
   control.  The classic use for this is
   the case where you want to select some data, then
   update it inside a transaction.
   If you don't explicit lock a table using LOCK statement, it will be
   implicit locked only at the first
   <command>UPDATE</command>, <command>INSERT</command>,
   or <command>DELETE</command> operation.
   If you don't exclusive lock the table before the select, some
   other user may also read the selected data, and try and do
   their own update, causing a deadlock while you both wait
   for the other to release the select-induced shared lock so
   you can get an exclusive lock to do the update.
  </para>
  <para>
   Another example of deadlock is where one user locks one
   table, and another user locks a second table. While both
   keep their existing locks, the first user tries to lock
   the second user's table, and the second user tries to lock
   the first user's table. Both users deadlock waiting for
   the tables to become available. The only solution to this
   is for both users to lock tables in the same order, so
   user's lock acquisitions and requests to not form a deadlock.
d249 35
d287 1
a287 2
    rollback transactions to resolve the deadlock. Usually, at least one
    of the deadlocked transactions will complete successfully.
d303 5
a308 8
    
    <note>
     <title>Bug</title>
     <para>
      If the locked table is dropped then it will be automatically
      unlocked even if a transaction is still in progress.
     </para>
    </note>
d317 1
d319 16
d336 2
d339 3
a341 1
    --Explicit locking to prevent deadlock:
d344 4
a347 4
    LOCK films;
    SELECT * FROM films;
    UPDATE films SET len = INTERVAL '100 minute'
      WHERE len = INTERVAL '117 minute';
d350 1
@


1.8
log
@Add mention of SHARE ROW EXCLUSIVE mode.
@
text
@d1 3
a3 3
<REFENTRY ID="SQL-LOCK">
 <REFMETA>
  <REFENTRYTITLE>
d5 5
a9 5
  </REFENTRYTITLE>
  <REFMISCINFO>SQL - Language Statements</REFMISCINFO>
 </REFMETA>
 <REFNAMEDIV>
  <REFNAME>
d11 2
a12 2
  </REFNAME>
  <REFPURPOSE>
d14 1
a14 1
  </REFPURPOSE>
d16 15
a30 14
 <REFSYNOPSISDIV>
  <REFSYNOPSISDIVINFO>
   <DATE>1998-09-24</DATE>
  </REFSYNOPSISDIVINFO>
  <SYNOPSIS>
   LOCK [ TABLE ] [IN [ROW|ACCESS] [SHARE|EXCLUSIVE] | [SHARE ROW EXCLUSIVE] MODE]
	<REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>
  </SYNOPSIS>

  <REFSECT2 ID="R2-SQL-LOCK-1">
   <REFSECT2INFO>
    <DATE>1998-09-01</DATE>
   </REFSECT2INFO>
   <TITLE>
d32 87
a118 17
   </TITLE>
   <PARA>
   </PARA>
   <VARIABLELIST>
    <VARLISTENTRY>
     <TERM>
      <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>
     </TERM>
     <LISTITEM>
      <PARA>
       The name of an existing table to lock.
      </para>
     </listitem>
    </varlistentry>
   </VARIABLELIST>
	  
  </REFSECT2>
d120 5
a124 5
  <REFSECT2 ID="R2-SQL-LOCK-2">
   <REFSECT2INFO>
    <DATE>1998-09-24</DATE>
   </REFSECT2INFO>
   <TITLE>
d126 2
a127 2
   </TITLE>
   <PARA>
d129 8
a136 7
    <VARIABLELIST>
      <TERM>
       ERROR <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>: Table does not exist.
      </TERM>
      <LISTITEM>
       <PARA>
	Message returned if <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>
d141 1
a141 1
    </VARIABLELIST>
d143 2
a144 2
  </REFSECT2>
 </REFSYNOPSISDIV>
d146 5
a150 5
 <REFSECT1 ID="R1-SQL-LOCK-1">
  <REFSECT1INFO>
   <DATE>1998-09-24</DATE>
  </REFSECT1INFO>
  <TITLE>
d152 2
a153 2
  </TITLE>
  <PARA>
d187 5
a191 5
  <REFSECT2 ID="R2-SQL-LOCK-3">
   <REFSECT2INFO>
    <DATE>1998-09-24</DATE>
   </REFSECT2INFO>
   <TITLE>
d193 1
a193 1
   </TITLE>
d209 1
a209 1
  </REFSECT2>
d212 2
a213 2
 <REFSECT1 ID="R1-SQL-LOCK-2">
  <TITLE>
d215 4
a218 4
  </TITLE>
  <PARA>
  </PARA>
  <ProgramListing>
d227 1
a227 1
  </ProgramListing>
d229 1
a229 1
 </REFSECT1>
d231 2
a232 2
 <REFSECT1 ID="R1-SQL-LOCK-3">
  <TITLE>
d234 1
a234 1
  </TITLE>
d236 5
a240 5
  <REFSECT2 ID="R2-SQL-LOCK-4">
   <REFSECT2INFO>
    <DATE>1998-09-24</DATE>
   </REFSECT2INFO>
   <TITLE>
d242 2
a243 2
   </TITLE>
   <PARA>
d250 1
a250 1
</REFENTRY>
@


1.7
log
@man page cleanup for vadim.
@
text
@d21 2
a22 1
   LOCK [ TABLE ] [IN [ROW|ACCESS] [SHARE|EXCLUSIVE] MODE] <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>
@


1.6
log
@Update lock sgml/man/psql help pages.
@
text
@d21 1
a21 1
   LOCK [ TABLE ] [[IN] [ROW|ACCESS] [SHARE|EXCLUSIVE] MODE] <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>
@


1.5
log
@Add reference pages on user interface applications.
@
text
@d21 1
a21 1
   LOCK [ TABLE ] <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>
a57 14
     <VARLISTENTRY>
      <TERM>
       DELETE 0
      </TERM>
      <LISTITEM>
       <PARA>
	Message returned on a successful lock.
	<command>LOCK</command> is implemented as a 
	<command>DELETE FROM <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE></command>
	which is guaranteed to not delete any rows.
       </para>
      </listitem>
     </varlistentry>
     <VARLISTENTRY>
d81 3
a83 2
   <command>LOCK</command> locks in exclusive mode a table inside
   a transaction. The classic use for this is
d173 1
a173 1
    concurrency level on transactions.
@


1.4
log
@Clean up to ensure tag completion as required by the newest versions
 of Norm's Modular Style Sheets and jade/docbook.
From Vince Vielhaber <vev@@michvhf.com>.
@
text
@d2 43
a44 43
<REFMETA>
<REFENTRYTITLE>
LOCK
</REFENTRYTITLE>
<REFMISCINFO>SQL - Language Statements</REFMISCINFO>
</REFMETA>
<REFNAMEDIV>
<REFNAME>
LOCK
</REFNAME>
<REFPURPOSE>
Explicit lock of a table inside a transaction
</REFPURPOSE>
  </refnamediv>
<REFSYNOPSISDIV>
<REFSYNOPSISDIVINFO>
<DATE>1998-09-24</DATE>
</REFSYNOPSISDIVINFO>
<SYNOPSIS>
LOCK [ TABLE ] <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>
</SYNOPSIS>

	<REFSECT2 ID="R2-SQL-LOCK-1">
	  <REFSECT2INFO>
		<DATE>1998-09-01</DATE>
	  </REFSECT2INFO>
	  <TITLE>
		Inputs
	  </TITLE>
	  <PARA>
	  </PARA>
	  <VARIABLELIST>
		<VARLISTENTRY>
		  <TERM>
			<REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>
		  </TERM>
		  <LISTITEM>
			<PARA>
			  The name of an existing table to lock.
			</para>
		  </listitem>
		</varlistentry>
	  </VARIABLELIST>
d46 40
a85 1
	</REFSECT2>
d87 64
a150 103
	<REFSECT2 ID="R2-SQL-LOCK-2">
	  <REFSECT2INFO>
		<DATE>1998-09-24</DATE>
	  </REFSECT2INFO>
	  <TITLE>
		Outputs
	  </TITLE>
	  <PARA>
		
		<VARIABLELIST>
		  <VARLISTENTRY>
			<TERM>
			  DELETE 0
			</TERM>
			<LISTITEM>
			  <PARA>
				Message returned on a successful lock.
				<command>LOCK</command> is implemented as a 
				<command>DELETE FROM <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE></command>
				which is guaranteed to not delete any rows.
			  </para>
			</listitem>
		  </varlistentry>
		  <VARLISTENTRY>
			<TERM>
			  ERROR <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>: Table does not exist.
			</TERM>
			<LISTITEM>
			  <PARA>
				Message returned if <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>
				does not exist.
				</para>
			</listitem>
		  </varlistentry>
		</VARIABLELIST>
	  </para>
	</REFSECT2>
  </REFSYNOPSISDIV>

  <REFSECT1 ID="R1-SQL-LOCK-1">
	<REFSECT1INFO>
	  <DATE>1998-09-24</DATE>
	</REFSECT1INFO>
	<TITLE>
	  Description
	</TITLE>
	<PARA>
	  <command>LOCK</command> locks in exclusive mode a table inside
	  a transaction. The classic use for this is
	  the case where you want to select some data, then
	  update it inside a transaction.
	  If you don't explicit lock a table using LOCK statement, it will be
	  implicit locked only at the first
	  <command>UPDATE</command>, <command>INSERT</command>,
	  or <command>DELETE</command> operation.
	  If you don't exclusive lock the table before the select, some
	  other user may also read the selected data, and try and do
	  their own update, causing a deadlock while you both wait
	  for the other to release the select-induced shared lock so
	  you can get an exclusive lock to do the update.
	</para>
	<para>
	  Another example of deadlock is where one user locks one
	  table, and another user locks a second table. While both
	  keep their existing locks, the first user tries to lock
	  the second user's table, and the second user tries to lock
	  the first user's table. Both users deadlock waiting for
	  the tables to become available. The only solution to this
	  is for both users to lock tables in the same order, so
	  user's lock acquisitions and requests to not form a deadlock.
	</para>
	<note>
	  <para>
		<productname>Postgres</productname> does detect deadlocks and will
		rollback transactions to resolve the deadlock. Usually, at least one
		of the deadlocked transactions will complete successfully.
	  </para>
	</note>

	<REFSECT2 ID="R2-SQL-LOCK-3">
	  <REFSECT2INFO>
		<DATE>1998-09-24</DATE>
	  </REFSECT2INFO>
	  <TITLE>
		Notes
	  </TITLE>
	  <para>
		<command>LOCK</command> is a <productname>Postgres</productname>
		language extension.
	  </para>
	  <para>
		<command>LOCK</command> works only inside transactions.
		
		<note>
		  <title>Bug</title>
		  <para>
			If the locked table is dropped then it will be automatically
			unlocked even if a transaction is still in progress.
		  </para>
		</note>
	  </para>
	</REFSECT2>
  </refsect1>
d152 16
a167 16
  <REFSECT1 ID="R1-SQL-LOCK-2">
	<TITLE>
	  Usage
	</TITLE>
	<PARA>
	</PARA>
	<ProgramListing>
	  --Explicit locking to prevent deadlock:
	  --
	  BEGIN WORK;
	  LOCK films;
	  SELECT * FROM films;
	  UPDATE films SET len = INTERVAL '100 minute'
	  WHERE len = INTERVAL '117 minute';
	  COMMIT WORK;
	</ProgramListing>
d169 1
a169 1
  </REFSECT1>
d171 4
a174 4
  <REFSECT1 ID="R1-SQL-LOCK-3">
	<TITLE>
	  Compatibility
	</TITLE>
d176 14
a189 14
	<REFSECT2 ID="R2-SQL-LOCK-4">
	  <REFSECT2INFO>
		<DATE>1998-09-24</DATE>
	  </REFSECT2INFO>
	  <TITLE>
		SQL92
	  </TITLE>
	  <PARA>
		There is no <command>LOCK TABLE</command> in <acronym>SQL92</acronym>,
		which instead uses <command>SET TRANSACTION</command> to specify
		concurrency level on transactions.
	  </para>
	</refsect2>
  </refsect1>
d191 17
@


1.3
log
@Minor cleanup in markup, especially in the Output section.
@
text
@d15 1
a15 1

d24 166
a189 154
<REFSECT2 ID="R2-SQL-LOCK-1">
<REFSECT2INFO>
<DATE>1998-09-01</DATE>
</REFSECT2INFO>
<TITLE>
Inputs
</TITLE>
<PARA>
</PARA>
<VARIABLELIST>
<VARLISTENTRY>
<TERM>
<REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>
</TERM>
<LISTITEM>
<PARA>
          The name of an existing table to lock.
</VARIABLELIST>

</REFSECT2>

<REFSECT2 ID="R2-SQL-LOCK-2">
<REFSECT2INFO>
<DATE>1998-09-24</DATE>
</REFSECT2INFO>
<TITLE>
Outputs
</TITLE>
<PARA>

<VARIABLELIST>
<VARLISTENTRY>
<TERM>
DELETE 0
</TERM>
<LISTITEM>
<PARA>
Message returned on a successful lock.
<command>LOCK</command> is implemented as a 
<command>DELETE FROM <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE></command>
which is guaranteed to not delete any rows.

<VARLISTENTRY>
<TERM>
ERROR <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>: Table does not exist.
</TERM>
<LISTITEM>
<PARA>
Message returned if <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>
 does not exist.

</VARIABLELIST>

</REFSECT2>
</REFSYNOPSISDIV>

<REFSECT1 ID="R1-SQL-LOCK-1">
<REFSECT1INFO>
<DATE>1998-09-24</DATE>
</REFSECT1INFO>
<TITLE>
Description
</TITLE>
<PARA>
   <command>LOCK</command> locks in exclusive mode a table inside
   a transaction. The classic use for this is
   the case where you want to select some data, then
   update it inside a transaction.
   If you don't explicit lock a table using LOCK statement, it will be
   implicit locked only at the first
 <command>UPDATE</command>, <command>INSERT</command>,
 or <command>DELETE</command> operation.
   If you don't exclusive lock the table before the select, some
   other user may also read the selected data, and try and do
   their own update, causing a deadlock while you both wait
   for the other to release the select-induced shared lock so
   you can get an exclusive lock to do the update.

<para>
   Another example of deadlock is where one user locks one
   table, and another user locks a second table. While both
   keep their existing locks, the first user tries to lock
   the second user's table, and the second user tries to lock
   the first user's table. Both users deadlock waiting for
   the tables to become available. The only solution to this
   is for both users to lock tables in the same order, so
   user's lock acquisitions and requests to not form a deadlock.

<note>
<para>
<productname>Postgres</productname> does detect deadlocks and will
rollback transactions to resolve the deadlock. Usually, at least one
of the deadlocked transactions will complete successfully.
</note>

<REFSECT2 ID="R2-SQL-LOCK-3">
<REFSECT2INFO>
<DATE>1998-09-24</DATE>
</REFSECT2INFO>
<TITLE>
Notes
</TITLE>
<PARA>
<command>LOCK</command> is a <productname>Postgres</productname>
 language extension.
<para>
<command>LOCK</command> works only inside transactions.

<note>
<title>Bug</title>
<para>
If the locked table is dropped then it will be automatically
            unlocked even if a transaction is still in progress.
</note>

</REFSECT2>

<REFSECT1 ID="R1-SQL-LOCK-2">
<TITLE>
Usage
</TITLE>
<PARA>
</PARA>
<ProgramListing>
--Explicit locking to prevent deadlock:
--
BEGIN WORK;
    LOCK films;
    SELECT * FROM films;
    UPDATE films SET len = INTERVAL '100 minute'
        WHERE len = INTERVAL '117 minute';
COMMIT WORK;
</ProgramListing>
        
</REFSECT1>

<REFSECT1 ID="R1-SQL-LOCK-3">
<TITLE>
Compatibility
</TITLE>
<PARA>

<REFSECT2 ID="R2-SQL-LOCK-4">
<REFSECT2INFO>
<DATE>1998-09-24</DATE>
</REFSECT2INFO>
<TITLE>
SQL92
</TITLE>
<PARA>
   There is no <command>LOCK TABLE</command> in <acronym>SQL92</acronym>,
 which instead uses <command>SET TRANSACTION</command> to specify
   concurrency level on transactions.

@


1.2
log
@Cleanup markup and minor editing to prepare for first release.
@
text
@a56 8
<replaceable>status</replaceable>
</TERM>
<LISTITEM>
<PARA>

<VARIABLELIST>
<VARLISTENTRY>
<TERM>
a74 1
</VARIABLELIST>
@


1.1
log
@Add more new pages.
@
text
@d18 1
a18 1
<DATE>1998-09-01</DATE>
d21 1
a21 1
LOCK [TABLE] <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>
d47 1
a47 1
<DATE>1998-04-15</DATE>
d53 9
a61 1
</PARA>
d80 2
a81 1
Message returned if table don't exist.
d84 1
d91 1
a91 1
<DATE>1998-04-15</DATE>
d97 1
a97 1
   The LOCK statement locks in exclusive mode a table inside
d102 3
a104 1
   implicit locked only at first UPDATE, INSERT or DELETE operation.
d120 8
a127 1
        
d130 1
a130 1
<DATE>1998-04-15</DATE>
d136 2
a137 1
LOCK is a PostgreSQL language extension.
d139 1
a139 1
LOCK works only inside transactions.
d157 8
a164 8
   --Explicit locking to prevent deadlock:
   --
   BEGIN WORK;
     LOCK films;
     SELECT * FROM films;
     UPDATE films SET len = INTERVAL '100 minute'
                WHERE len = INTERVAL '117 minute';
   COMMIT WORK;
a173 1
</PARA>
d177 1
a177 1
<DATE>1998-04-15</DATE>
d184 1
a184 1
 it uses SET TRANSACTION to specify
d186 1
@
