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

diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index a6c0788592b06f5baab49791b3e3f09586dbdad2..b6b66bf068c51917df8d4bbbab3b20d7ea9a1f5e 100644 (file)
--- a/doc/src/sgml/ref/pg_dump.sgml
+++ b/doc/src/sgml/ref/pg_dump.sgml
@@ -372,8 +372,8 @@ PostgreSQL documentation
        
         Requesting exclusive locks on database objects while running a parallel dump could
         cause the dump to fail. The reason is that the pg_dump leader process
-        requests shared locks on the objects that the worker processes are going to dump later
-        in order to
+        requests shared locks (ACCESS SHARE) 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