database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

code: replace 'master' with 'leader' where appropriate.

Browse Source 
Leader already is the more widely used terminology, but a few places
didn't get the message.

Author: Andres Freund
Reviewed-By: David Steele
Discussion: https://postgr.es/m/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de
This commit is contained in:
Andres Freund
2020-06-14 14:22:47 -07:00
parent 5e7bbb5286
commit e07633646a
18 changed files with 120 additions and 120 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
doc/src/sgml/ref/pg_dump.sgml
View File

@ -332,12 +332,12 @@ 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> master process
cause the dump to fail. The reason is that the <application>pg_dump</application> leader process
requests shared locks 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 master process to be
granted but will be queued waiting for the shared lock of the leader process to be
released. Consequently any other access to the table will not be granted either and
will queue after the exclusive lock request. This includes the worker process trying
to dump the table. Without any precautions this would be a classic deadlock situation.
@ -354,14 +354,14 @@ PostgreSQL documentation
for standbys. With this feature, database clients can ensure they see
the same data set even though they use different connections.
<command>pg_dump -j</command> uses multiple database connections; it
connects to the database once with the master process and once again
connects to the database once with the leader process and once again
for each worker job. Without the synchronized snapshot feature, the
different worker jobs wouldn't be guaranteed to see the same data in
each connection, which could lead to an inconsistent backup.
</para>
<para>
If you want to run a parallel dump of a pre-9.2 server, you need to make sure that the
database content doesn't change from between the time the master connects to the
database content doesn't change from between the time the leader connects to the
database until the last worker job has connected to the database. The easiest way to
do this is to halt any data modifying processes (DDL and DML) accessing the database
before starting the backup. You also need to specify the