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

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

1 files changed, 4 insertions, 4 deletions

diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index 8aadaa2a12e..d5fb5430dc8 100644
--- a/doc/src/sgml/ref/pg_dump.sgml
+++ b/doc/src/sgml/ref/pg_dump.sgml
@@ -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