v2-0001-Specify-correctly-the-locks-pg_dump-takes.patch
text/plain
Filename: v2-0001-Specify-correctly-the-locks-pg_dump-takes.patch
Type: text/plain
Part: 0
Patch
Format: format-patch
Series: patch v2-0001
Subject: Specify correctly the locks pg_dump takes
| File | + | − |
|---|---|---|
| doc/src/sgml/ref/pg_dump.sgml | 2 | 2 |
From 13c57e5218b605bd9d101e966b8edb486daac091 Mon Sep 17 00:00:00 2001
From: Florin Irion <florin.irion@enterprisedb.com>
Date: Tue, 15 Mar 2022 22:43:34 +0100
Subject: [PATCH v2] 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 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index 2f0042fd96..07edd459cf 100644
--- a/doc/src/sgml/ref/pg_dump.sgml
+++ b/doc/src/sgml/ref/pg_dump.sgml
@@ -372,8 +372,8 @@ 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
- in order to
+ requests shared locks (<link linkend="locking-tables">ACCESS SHARE</link>) 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
--
2.34.0