aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJohn Naylor <john.naylor@postgresql.org>2022-07-01 11:41:36 +0700
committerJohn Naylor <john.naylor@postgresql.org>2022-07-15 08:18:44 +0700
commitb32a588961161ba36d01ff8dbccfc949493232c7 (patch)
treee35530636bc2a0952b21f53df58293eddc6a44e2
parentad8c8ee415da2d5437a346f1a57d873467d60812 (diff)
downloadpostgresql-b32a588961161ba36d01ff8dbccfc949493232c7.tar.gz
postgresql-b32a588961161ba36d01ff8dbccfc949493232c7.zip
Clarify that pg_dump takes ACCESS SHARE lock
Add link to the description of lock levels to avoid confusing "shared locks" with SHARE locks. Florin Irion Reviewed-by: Álvaro Herrera, Tom Lane, and Nathan Bossart Discussion: https://www.postgresql.org/message-id/flat/d0f30cc2-3c76-1d43-f291-7c4b2872d653@gmail.com This is a backpatch of 4e2e8d71f, applied through version 14
-rw-r--r--doc/src/sgml/ref/pg_dump.sgml4
1 files changed, 2 insertions, 2 deletions
diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index c9467557377..5efb442b443 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