1- <!-- $PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.64 2006/10/20 20:35:13 neilc Exp $ -->
1+ <!-- $PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.65 2006/12/01 01:04:36 tgl Exp $ -->
22
33 <chapter id="mvcc">
44 <title>Concurrency Control</title>
@@ -504,16 +504,17 @@ SELECT SUM(value) FROM mytab WHERE class = 2;
504504 most <productname>PostgreSQL</productname> commands automatically
505505 acquire locks of appropriate modes to ensure that referenced
506506 tables are not dropped or modified in incompatible ways while the
507- command executes. (For example, <command>ALTER TABLE</> cannot be
508- executed concurrently with other operations on the same table.)
507+ command executes. (For example, <command>ALTER TABLE</> cannot safely be
508+ executed concurrently with other operations on the same table, so it
509+ obtains an exclusive lock on the table to enforce that.)
509510 </para>
510511
511512 <para>
512513 To examine a list of the currently outstanding locks in a database
513- server, use the <structname>pg_locks</structname> system view
514- (<xref linkend="view-pg-locks">). For more
515- information on monitoring the status of the lock manager
516- subsystem, refer to <xref linkend="monitoring">.
514+ server, use the
515+ <link linkend="view-pg-locks"><structname>pg_locks</structname></link>
516+ system view. For more information on monitoring the status of the lock
517+ manager subsystem, refer to <xref linkend="monitoring">.
517518 </para>
518519
519520 <sect2 id="locking-tables">
@@ -545,7 +546,6 @@ SELECT SUM(value) FROM mytab WHERE class = 2;
545546 an <literal>ACCESS EXCLUSIVE</literal> lock cannot be held by more than one
546547 transaction at a time) while others are not self-conflicting (for example,
547548 an <literal>ACCESS SHARE</literal> lock can be held by multiple transactions).
548- Once acquired, a lock is held till end of transaction.
549549 </para>
550550
551551 <variablelist>
@@ -731,6 +731,16 @@ SELECT SUM(value) FROM mytab WHERE class = 2;
731731 </para>
732732 </tip>
733733
734+ <para>
735+ Once acquired, a lock is normally held till end of transaction. But if a
736+ lock is acquired after establishing a savepoint, the lock is released
737+ immediately if the savepoint is rolled back to. This is consistent with
738+ the principle that <command>ROLLBACK</> cancels all effects of the
739+ commands since the savepoint. The same holds for locks acquired within a
740+ <application>PL/pgSQL</> exception block: an error escape from the block
741+ releases locks acquired within it.
742+ </para>
743+
734744 </sect2>
735745
736746 <sect2 id="locking-rows">
@@ -741,8 +751,9 @@ SELECT SUM(value) FROM mytab WHERE class = 2;
741751 can be exclusive or shared locks. An exclusive row-level lock on a
742752 specific row is automatically acquired when the row is updated or
743753 deleted. The lock is held until the transaction commits or rolls
744- back. Row-level locks do not affect data querying; they block
745- <emphasis>writers to the same row</emphasis> only.
754+ back, in just the same way as for table-level locks. Row-level locks do
755+ not affect data querying; they block <emphasis>writers to the same
756+ row</emphasis> only.
746757 </para>
747758
748759 <para>
@@ -759,7 +770,7 @@ SELECT SUM(value) FROM mytab WHERE class = 2;
759770 other transactions from acquiring the same shared lock. However,
760771 no transaction is allowed to update, delete, or exclusively lock a
761772 row on which any other transaction holds a shared lock. Any attempt
762- to do so will block until the sharedlocks have been released.
773+ to do so will block until the sharedlock(s) have been released.
763774 </para>
764775
765776 <para>
@@ -882,10 +893,11 @@ UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;
882893 that are an awkward fit for the MVCC model. Once acquired, an
883894 advisory lock is held until explicitly released or the session ends.
884895 Unlike standard locks, advisory locks do not
885- honor transaction semantics. For example, a lock acquired during a
896+ honor transaction semantics: a lock acquired during a
886897 transaction that is later rolled back will still be held following the
887- rollback. The same lock can be acquired multiple times by its
888- owning process: for each lock request there must be a corresponding
898+ rollback, and likewise an unlock is effective even if the calling
899+ transaction fails later. The same lock can be acquired multiple times by
900+ its owning process: for each lock request there must be a corresponding
889901 unlock request before the lock is actually released. (If a session
890902 already holds a given lock, additional requests will always succeed, even
891903 if other sessions are awaiting the lock.) Like all locks in