Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit b32a588

Browse files
committed
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 4e2e8d7, applied through version 14
1 parent ad8c8ee commit b32a588

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

doc/src/sgml/ref/pg_dump.sgml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -372,8 +372,8 @@ PostgreSQL documentation
372372
<para>
373373
Requesting exclusive locks on database objects while running a parallel dump could
374374
cause the dump to fail. The reason is that the <application>pg_dump</application> leader process
375-
requests shared locks on the objects that the worker processes are going to dump later
376-
in order to
375+
requests shared locks (<link linkend="locking-tables">ACCESS SHARE</link>) on the
376+
objects that the worker processes are going to dump later in order to
377377
make sure that nobody deletes them and makes them go away while the dump is running.
378378
If another client then requests an exclusive lock on a table, that lock will not be
379379
granted but will be queued waiting for the shared lock of the leader process to be

0 commit comments

Comments
 (0)