aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAndres Freund <andres@anarazel.de>2020-06-15 10:19:32 -0700
committerAndres Freund <andres@anarazel.de>2020-07-08 13:20:15 -0700
commit7c89f8a5b810d10dae300ec58ea7d70024e9123e (patch)
tree59ae4298b431271fe1b3b8459661d341ac81d1ed
parent09dfd430118f1fadf52a782db5ee161b1eb16337 (diff)
downloadpostgresql-7c89f8a5b810d10dae300ec58ea7d70024e9123e.tar.gz
postgresql-7c89f8a5b810d10dae300ec58ea7d70024e9123e.zip
docs: replace 'master process' with 'supervisor process' where appropriate.
Author: Andres Freund Reviewed-By: David Steele Discussion: https://postgr.es/m/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de
-rw-r--r--doc/src/sgml/arch-dev.sgml5
-rw-r--r--doc/src/sgml/runtime.sgml6
-rw-r--r--doc/src/sgml/start.sgml2
3 files changed, 7 insertions, 6 deletions
diff --git a/doc/src/sgml/arch-dev.sgml b/doc/src/sgml/arch-dev.sgml
index 9ffb8427bf0..7883c3cd827 100644
--- a/doc/src/sgml/arch-dev.sgml
+++ b/doc/src/sgml/arch-dev.sgml
@@ -122,8 +122,9 @@
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>
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 1fd4ab723c2..331d01b4445 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -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
diff --git a/doc/src/sgml/start.sgml b/doc/src/sgml/start.sgml
index 2a47f69079b..9bb5c1a6d5d 100644
--- a/doc/src/sgml/start.sgml
+++ b/doc/src/sgml/start.sgml
@@ -113,7 +113,7 @@
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.)