Hi,
In the `pg_dump` documentation we talk about "shared locks", but IIUC, we
actually take `AccessShareLock`s.
This might be misunderstood with the `ShareLock`.
There are 5 occurrences. 4 in `--jobs=njobs` and 1 in
`--lock-wait-timeout=timeout` sections.
Cheers,
Florin Irion
From 63adb1d3a252d78a115a0bae3e9c6bc08b7ae83f Mon Sep 17 00:00:00 2001
From: Florin Irion <florin.ir...@enterprisedb.com>
Date: Tue, 15 Mar 2022 15:09:11 +0100
Subject: [PATCH] doc: Specify correctly the locks pg_dump takes
The pg_dump leader and worker processes take `AccessShareLock`s,
clarify it in the docs so that it can not be misunderstood with
`ShareLock`s.
---
doc/src/sgml/ref/pg_dump.sgml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index 2f0042fd96..5f95b16e98 100644
--- a/doc/src/sgml/ref/pg_dump.sgml
+++ b/doc/src/sgml/ref/pg_dump.sgml
@@ -372,17 +372,17 @@ PostgreSQL documentation
<para>
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 access share locks on the objects that the worker processes
are going to dump later
in order to
make sure that nobody deletes them and makes them go away while the
dump is running.
If another client then requests an exclusive lock on a table, that
lock will not be
- granted but will be queued waiting for the shared lock of the leader
process to be
+ granted but will be queued waiting for the access share lock of the
leader process to be
released. Consequently any other access to the table will not be
granted either and
will queue after the exclusive lock request. This includes the worker
process trying
to dump the table. Without any precautions this would be a classic
deadlock situation.
To detect this conflict, the <application>pg_dump</application> worker
process requests another
- shared lock using the <literal>NOWAIT</literal> option. If the worker
process is not granted
- this shared lock, somebody else must have requested an exclusive lock
in the meantime
+ access share lock using the <literal>NOWAIT</literal> option. If the
worker process is not granted
+ this access share lock, somebody else must have requested an exclusive
lock in the meantime
and there is no way to continue with the dump, so
<application>pg_dump</application> has no choice
but to abort the dump.
</para>
@@ -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
+ Do not wait forever to acquire access share table locks at the
beginning of
the dump. Instead fail if unable to lock a table within the specified
<replaceable class="parameter">timeout</replaceable>. The timeout may
be
specified in any of the formats accepted by <command>SET
--
2.34.0
