Date: Tue, 15 Mar 2022 16:06:57 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Florin Irion <irionr@gmail.com>
Cc: pgsql-docs@lists.postgresql.org
Subject: Re: pg_dump shared locks documentation
Message-ID: <202203151506.55cjea5lmp2l@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <d0f30cc2-3c76-1d43-f291-7c4b2872d653@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202203151506.55cjea5lmp2l%40alvherre.pgsql>
Precedence: bulk

On 2022-Mar-15, Florin Irion wrote:

> In the `pg_dump` documentation we talk about "shared locks", but IIUC,
> we actually take `AccessShareLock`s.  This might be misunderstood with
> the `ShareLock`.

This might be a bit excessive to have in the main text.  What about
adding a footnote to point out the exact lock level that is meant, with
a link to the server doc page that explains each lock level?
Something like this:

>          Requesting exclusive locks on database objects while running a parallel dump could
>          cause the dump to fail. The reason is that the <application>pg_dump</application> leader process
> -        requests shared locks on the objects that the worker processes are going to dump later
> +        requests shared locks<footnote>The precise lock level used is <literal>ACCESS SHARE</literal>.
> +        See <xref ... /> for more information.</footnote> on the objects that the worker processes are
>          going to dump later

...

> @@ -870,7 +870,7 @@ PostgreSQL documentation
>        <term><option>--lock-wait-timeout=<replaceable class="parameter">timeout</replaceable></option></term>
>        <listitem>
>         <para>
> -        Do not wait forever to acquire shared table locks at the beginning of

Same here.

-- 
Álvaro Herrera