Adjust the description of locking to clarify that locks held by a
subtransaction are released if the subtransaction aborts --- in user-level terminology, this means either rolling back to a savepoint or escaping from a plpgsql exception block. Per recent suggestion from Simon.
This commit is contained in:
parent
746330e2d0
commit
da6daee216
|
@ -1,4 +1,4 @@
|
||||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.64 2006/10/20 20:35:13 neilc Exp $ -->
|
<!-- $PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.65 2006/12/01 01:04:36 tgl Exp $ -->
|
||||||
|
|
||||||
<chapter id="mvcc">
|
<chapter id="mvcc">
|
||||||
<title>Concurrency Control</title>
|
<title>Concurrency Control</title>
|
||||||
|
@ -504,16 +504,17 @@ SELECT SUM(value) FROM mytab WHERE class = 2;
|
||||||
most <productname>PostgreSQL</productname> commands automatically
|
most <productname>PostgreSQL</productname> commands automatically
|
||||||
acquire locks of appropriate modes to ensure that referenced
|
acquire locks of appropriate modes to ensure that referenced
|
||||||
tables are not dropped or modified in incompatible ways while the
|
tables are not dropped or modified in incompatible ways while the
|
||||||
command executes. (For example, <command>ALTER TABLE</> cannot be
|
command executes. (For example, <command>ALTER TABLE</> cannot safely be
|
||||||
executed concurrently with other operations on the same table.)
|
executed concurrently with other operations on the same table, so it
|
||||||
|
obtains an exclusive lock on the table to enforce that.)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
To examine a list of the currently outstanding locks in a database
|
To examine a list of the currently outstanding locks in a database
|
||||||
server, use the <structname>pg_locks</structname> system view
|
server, use the
|
||||||
(<xref linkend="view-pg-locks">). For more
|
<link linkend="view-pg-locks"><structname>pg_locks</structname></link>
|
||||||
information on monitoring the status of the lock manager
|
system view. For more information on monitoring the status of the lock
|
||||||
subsystem, refer to <xref linkend="monitoring">.
|
manager subsystem, refer to <xref linkend="monitoring">.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<sect2 id="locking-tables">
|
<sect2 id="locking-tables">
|
||||||
|
@ -545,7 +546,6 @@ SELECT SUM(value) FROM mytab WHERE class = 2;
|
||||||
an <literal>ACCESS EXCLUSIVE</literal> lock cannot be held by more than one
|
an <literal>ACCESS EXCLUSIVE</literal> lock cannot be held by more than one
|
||||||
transaction at a time) while others are not self-conflicting (for example,
|
transaction at a time) while others are not self-conflicting (for example,
|
||||||
an <literal>ACCESS SHARE</literal> lock can be held by multiple transactions).
|
an <literal>ACCESS SHARE</literal> lock can be held by multiple transactions).
|
||||||
Once acquired, a lock is held till end of transaction.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<variablelist>
|
<variablelist>
|
||||||
|
@ -731,6 +731,16 @@ SELECT SUM(value) FROM mytab WHERE class = 2;
|
||||||
</para>
|
</para>
|
||||||
</tip>
|
</tip>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Once acquired, a lock is normally held till end of transaction. But if a
|
||||||
|
lock is acquired after establishing a savepoint, the lock is released
|
||||||
|
immediately if the savepoint is rolled back to. This is consistent with
|
||||||
|
the principle that <command>ROLLBACK</> cancels all effects of the
|
||||||
|
commands since the savepoint. The same holds for locks acquired within a
|
||||||
|
<application>PL/pgSQL</> exception block: an error escape from the block
|
||||||
|
releases locks acquired within it.
|
||||||
|
</para>
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 id="locking-rows">
|
<sect2 id="locking-rows">
|
||||||
|
@ -741,8 +751,9 @@ SELECT SUM(value) FROM mytab WHERE class = 2;
|
||||||
can be exclusive or shared locks. An exclusive row-level lock on a
|
can be exclusive or shared locks. An exclusive row-level lock on a
|
||||||
specific row is automatically acquired when the row is updated or
|
specific row is automatically acquired when the row is updated or
|
||||||
deleted. The lock is held until the transaction commits or rolls
|
deleted. The lock is held until the transaction commits or rolls
|
||||||
back. Row-level locks do not affect data querying; they block
|
back, in just the same way as for table-level locks. Row-level locks do
|
||||||
<emphasis>writers to the same row</emphasis> only.
|
not affect data querying; they block <emphasis>writers to the same
|
||||||
|
row</emphasis> only.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
@ -759,7 +770,7 @@ SELECT SUM(value) FROM mytab WHERE class = 2;
|
||||||
other transactions from acquiring the same shared lock. However,
|
other transactions from acquiring the same shared lock. However,
|
||||||
no transaction is allowed to update, delete, or exclusively lock a
|
no transaction is allowed to update, delete, or exclusively lock a
|
||||||
row on which any other transaction holds a shared lock. Any attempt
|
row on which any other transaction holds a shared lock. Any attempt
|
||||||
to do so will block until the shared locks have been released.
|
to do so will block until the shared lock(s) have been released.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
@ -882,10 +893,11 @@ UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;
|
||||||
that are an awkward fit for the MVCC model. Once acquired, an
|
that are an awkward fit for the MVCC model. Once acquired, an
|
||||||
advisory lock is held until explicitly released or the session ends.
|
advisory lock is held until explicitly released or the session ends.
|
||||||
Unlike standard locks, advisory locks do not
|
Unlike standard locks, advisory locks do not
|
||||||
honor transaction semantics. For example, a lock acquired during a
|
honor transaction semantics: a lock acquired during a
|
||||||
transaction that is later rolled back will still be held following the
|
transaction that is later rolled back will still be held following the
|
||||||
rollback. The same lock can be acquired multiple times by its
|
rollback, and likewise an unlock is effective even if the calling
|
||||||
owning process: for each lock request there must be a corresponding
|
transaction fails later. The same lock can be acquired multiple times by
|
||||||
|
its owning process: for each lock request there must be a corresponding
|
||||||
unlock request before the lock is actually released. (If a session
|
unlock request before the lock is actually released. (If a session
|
||||||
already holds a given lock, additional requests will always succeed, even
|
already holds a given lock, additional requests will always succeed, even
|
||||||
if other sessions are awaiting the lock.) Like all locks in
|
if other sessions are awaiting the lock.) Like all locks in
|
||||||
|
|
Loading…
Reference in New Issue