Date: Thu, 12 Mar 2020 16:34:20 -0400
From: Bruce Momjian <bruce@momjian.us>
To: me@sillymon.ch, pgsql-docs@lists.postgresql.org
Subject: Re: Move description of general lock behaviour out of the "13.3.1.
 Table-level Locks section"
Message-ID: <20200312203420.GA2309@momjian.us>
References: <158074944048.1095.4309647363871637715@wrigleys.postgresql.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="y0ulUmNC+osPPQO6"
Content-Disposition: inline
In-Reply-To: <158074944048.1095.4309647363871637715@wrigleys.postgresql.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk


--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Feb  3, 2020 at 05:04:00PM +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
> 
> Page: https://www.postgresql.org/docs/9.4/explicit-locking.html
> Description:
> 
> Hi
> 
> The "13.3.1. Table-level Locks" subsection mentions the following: "Once
> acquired, a lock is normally held till end of transaction." (maybe we should
> also squeeze a "...till the end of a transaction" in there) According to a

Sorry for the delay in replying.  Yes, this wording needs improvement,
which I have done in the attached patch.

> helpful stranger on IRC, this behavior is also true for row-level locks.
> 
> Since this sentence also applies to the row-level locks described in the
> following subsection 13.3.2 I think it would be more fitting to move the
> paragraph containing this sentence to the introduction of the topic in
> section "13.3. Explicit Locking". This would then read something like:

Uh, we can't move that paragraph up because Page-Level Locks and
Advisory Locks aren't always released on transaction end or rollback. 
What I did do was to mention that row-level locks are released in a
similar way to table-level locks.

Patch attached.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

--y0ulUmNC+osPPQO6
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="lock.diff"

diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index f8c9655111..95465d581b 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -1039,9 +1039,9 @@ ERROR:  could not serialize access due to read/write dependencies among transact
      </tip>
 
    <para>
-    Once acquired, a lock is normally held till end of transaction.  But if a
+    Once acquired, a lock is normally held until the end of the 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
+    immediately if the savepoint is rolled back.  This is consistent with
     the principle that <command>ROLLBACK</command> cancels all effects of the
     commands since the savepoint.  The same holds for locks acquired within a
     <application>PL/pgSQL</application> exception block: an error escape from the block
@@ -1178,7 +1178,10 @@ ERROR:  could not serialize access due to read/write dependencies among transact
      conflicting locks on the same row, even in different subtransactions;
      but other than that, two transactions can never hold conflicting locks
      on the same row.  Row-level locks do not affect data querying; they
-     block only <emphasis>writers and lockers</emphasis> to the same row.
+     block only <emphasis>writers and lockers</emphasis> to the same
+     row.  Row-level locks are released at transaction end or during
+     savepoint rollback, just like table-level locks.
+
     </para>
 
      <variablelist>

--y0ulUmNC+osPPQO6--