doc: Adjust a few more references to "postmaster"

Reported-by: Karl O. Pinc 
Discussion: https://www.postgresql.org/message-id/flat/ece84b69-8f94-8b88-925f-64207cb3a2f0@enterprisedb.com

diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 9e87e07dfeac481d5b5574db346dfca5ad13aaca..149e9b33d4841f2bf2588c5c84c895b12815900a 100644 (file)
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1306,12 +1306,12 @@ default:\
     Another kernel limit that may be of concern when supporting large
     numbers of client connections is the maximum socket connection queue
     length.  If more than that many connection requests arrive within a very
-    short period, some may get rejected before the postmaster can service
+    short period, some may get rejected before the PostgreSQL server can service
     the requests, with those clients receiving unhelpful connection failure
     errors such as Resource temporarily unavailable or
     Connection refused.  The default queue length limit is 128
     on many platforms.  To raise it, adjust the appropriate kernel parameter
-    via sysctl, then restart the postmaster.
+    via sysctl, then restart the PostgreSQL server.
     The parameter is variously named net.core.somaxconn
     on Linux, kern.ipc.soacceptqueue on newer FreeBSD,
     and kern.ipc.somaxconn on macOS and other BSD
@@ -1409,11 +1409,12 @@ sysctl -w vm.overcommit_memory=2
 
 echo -1000 > /proc/self/oom_score_adj
 
-    in the postmaster's startup script just before invoking the postmaster.
+    in the PostgreSQL startup script just before
+    invoking postgres.
     Note that this action must be done as root, or it will have no effect;
     so a root-owned startup script is the easiest place to do it.  If you
     do this, you should also set these environment variables in the startup
-    script before invoking the postmaster:
+    script before invoking postgres:
 
 export PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj
 export PG_OOM_ADJUST_VALUE=0