From: Bruce Momjian <bruce@momjian.us>
To: me@sillymon.ch
To: pgsql-docs@lists.postgresql.org
Subject: Re: Move description of general lock behaviour out of the "13.3.1. Table-level Locks section"
Date: Thu, 12 Mar 2020 16:34:20 -0400
Message-ID: <20200312203420.GA2309@momjian.us> (raw)
In-Reply-To: <158074944048.1095.4309647363871637715@wrigleys.postgresql.org>
References: <158074944048.1095.4309647363871637715@wrigleys.postgresql.org>
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 +
Attachments:
[text/x-diff] lock.diff (1.5K, ../20200312203420.GA2309@momjian.us/2-lock.diff)
download | inline diff:diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgmlindex 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>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: bruce@momjian.us, 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"
In-Reply-To: <20200312203420.GA2309@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox