This is an automated email from the ASF dual-hosted git repository. reshke pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/cloudberry.git
commit e90d7dd0eee199b24751070ae1078a2359b77cd6 Author: John Naylor <[email protected]> AuthorDate: Fri Jul 1 11:41:36 2022 +0700 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/[email protected] This is a backpatch of 4e2e8d71f, applied through version 14 --- doc/src/sgml/ref/pg_dump.sgml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml index ca6ff8cdc65..6a7cd8dff4f 100644 --- a/doc/src/sgml/ref/pg_dump.sgml +++ b/doc/src/sgml/ref/pg_dump.sgml @@ -371,9 +371,9 @@ PostgreSQL documentation </para> <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> coordinator process - requests shared locks on the objects that the worker processes are going to dump later - in order to + cause the dump to fail. The reason is that the <application>pg_dump</application> leader process + 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 coordinator process to be --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
