docs: replace 'master process' with 'supervisor process' where appropriate.
authorAndres Freund <andres@anarazel.de>
Mon, 15 Jun 2020 17:19:32 +0000 (10:19 -0700)
committerAndres Freund <andres@anarazel.de>
Wed, 8 Jul 2020 20:20:15 +0000 (13:20 -0700)
Author: Andres Freund
Reviewed-By: David Steele
Discussion: https://postgr.es/m/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de

doc/src/sgml/arch-dev.sgml
doc/src/sgml/runtime.sgml
doc/src/sgml/start.sgml

index 9ffb8427bf09f263bcb10b449a22e7d556e437a8..7883c3cd827ce54e76225a2a4f1cc397a36ab9e4 100644 (file)
     there is one <firstterm>client process</firstterm> connected to
     exactly one <firstterm>server process</firstterm>.  As we do not
     know ahead of time how many connections will be made, we have to
-    use a <firstterm>master process</firstterm> that spawns a new
-    server process every time a connection is requested. This master
+    use a <firstterm>supervisor process</firstterm> (also
+    <firstterm>master process</firstterm>) that spawns a new
+    server process every time a connection is requested. This supervisor
     process is called <literal>postgres</literal> and listens at a
     specified TCP/IP port for incoming connections. Whenever a request
     for a connection is detected the <literal>postgres</literal>
index 1fd4ab723c2e9d347bc2048d7e0deb7789052f87..331d01b4445a1155173273023d7abbb349e88d8e 100644 (file)
@@ -1292,7 +1292,7 @@ default:\
     optimal for <productname>PostgreSQL</productname>. Because of the
     way that the kernel implements memory overcommit, the kernel might
     terminate the <productname>PostgreSQL</productname> postmaster (the
-    master server process) if the memory demands of either
+    supervisor server process) if the memory demands of either
     <productname>PostgreSQL</productname> or another process cause the
     system to run out of virtual memory.
    </para>
@@ -1465,7 +1465,7 @@ $ <userinput>grep Huge /proc/meminfo</userinput>
 
   <para>
    There are several ways to shut down the database server. You control
-   the type of shutdown by sending different signals to the master
+   the type of shutdown by sending different signals to the supervisor
    <command>postgres</command> process.
 
    <variablelist>
@@ -1511,7 +1511,7 @@ $ <userinput>grep Huge /proc/meminfo</userinput>
       The server will send <systemitem>SIGQUIT</systemitem> to all child
       processes and wait for them to terminate.  If any do not terminate
       within 5 seconds, they will be sent <systemitem>SIGKILL</systemitem>.
-      The master server process exits as soon as all child processes have
+      The supervisor server process exits as soon as all child processes have
       exited, without doing normal database shutdown processing.
       This will lead to recovery (by
       replaying the WAL log) upon next start-up. This is recommended
index 2a47f69079bffab05b4e9eb1d8ab422fd7c36ef6..9bb5c1a6d5d1f6ee7c007908002875cfb42d96e4 100644 (file)
     From that point on, the client and the new server process
     communicate without intervention by the original
     <filename>postgres</filename> process.  Thus, the
-    master server process is always running, waiting for
+    supervisor server process is always running, waiting for
     client connections, whereas client and associated server processes
     come and go.  (All of this is of course invisible to the user.  We
     only mention it here for completeness.)