Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit4e2e8d7

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 IrionReviewed-by: Álvaro Herrera, Tom Lane, and Nathan BossartDiscussion:https://www.postgresql.org/message-id/flat/d0f30cc2-3c76-1d43-f291-7c4b2872d653@gmail.com
1 parent389869a commit4e2e8d7

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 lockson 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 laterin 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)

[8]ページ先頭

©2009-2025 Movatter.jp