ok
Direktori : /opt/alt/postgresql11/usr/share/doc/alt-postgresql11-9.2.24/html/ |
Current File : //opt/alt/postgresql11/usr/share/doc/alt-postgresql11-9.2.24/html/sql-lock.html |
<!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 9.2.24 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="2017-11-06T22:43: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" ><A HREF="index.html" >PostgreSQL 9.2.24 Documentation</A ></TH ></TR ><TR ><TD WIDTH="10%" ALIGN="left" VALIGN="top" ><A TITLE="LOAD" HREF="sql-load.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="10%" ALIGN="left" VALIGN="top" ><A HREF="sql-commands.html" ACCESSKEY="U" >Up</A ></TD ><TD WIDTH="60%" ALIGN="center" VALIGN="bottom" ></TD ><TD WIDTH="20%" ALIGN="right" VALIGN="top" ><A TITLE="MOVE" 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="AEN76324" ></A ><H2 >Name</H2 >LOCK -- lock a table</DIV ><DIV CLASS="REFSYNOPSISDIV" ><A NAME="AEN76329" ></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 ] <SPAN CLASS="phrase" ><SPAN CLASS="PHRASE" >where <TT CLASS="REPLACEABLE" ><I >lockmode</I ></TT > is one of:</SPAN ></SPAN > ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE</PRE ></DIV ><DIV CLASS="REFSECT1" ><A NAME="AEN76335" ></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 <TT CLASS="LITERAL" >REPEATABLE READ</TT > or <TT CLASS="LITERAL" >SERIALIZABLE</TT > 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 <TT CLASS="LITERAL" >REPEATABLE READ</TT > or <TT CLASS="LITERAL" >SERIALIZABLE</TT > 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 — 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 — 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="AEN76370" ></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 before the table name, 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. Optionally, <TT CLASS="LITERAL" >*</TT > can be specified after the table name to explicitly indicate that descendant tables are included. </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="AEN76399" ></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 table-level <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" >BEGIN</A > and <A HREF="sql-commit.html" >COMMIT</A > (or <A HREF="sql-rollback.html" >ROLLBACK</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="AEN76423" ></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 < 5); DELETE FROM films WHERE rating < 5; COMMIT WORK;</PRE ><P></P ></DIV ><DIV CLASS="REFSECT1" ><A NAME="AEN76431" ></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" >SET TRANSACTION</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 >