Commitb32a588

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.comThis is a backpatch of4e2e8d7, applied through version 14

1 parentad8c8ee commitb32a588Copy full SHA for b32a588

File tree

-2

lines changed

-2

lines changed

Lines changed: 2 additions & 2 deletions

Original file line number	Diff line number	Diff line change
`@@ -372,8 +372,8 @@ PostgreSQL documentation`
`372`	`372`	`<para>`
`373`	`373`	`Requesting exclusive locks on database objects while running a parallel dump could`
`374`	`374`	`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`
`377`	`377`	`make sure that nobody deletes them and makes them go away while the dump is running.`
`378`	`378`	`If another client then requests an exclusive lock on a table, that lock will not be`
`379`	`379`	`granted but will be queued waiting for the shared lock of the leader process to be`

Comments

(0)