Doc: Update example symptom of systemd misconfiguration.

In PostgreSQL 10, we stopped using System V semaphores on Linux
systems.  Update the example we give of an error message from a
misconfigured system to show what people are most likely to see these
days.

Back-patch to 10, where PREFERRED_SEMAPHORES=UNNAMED_POSIX arrived.

Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CA%2BhUKGLmJUSwybaPQv39rB8ABpqJq84im2UjZvyUY4feYhpWMw%40mail.gmail.com

Author: macdice

doc/src/sgml/runtime.sgml

@@ -1120,7 +1120,7 @@ project.max-msg-ids=(priv,4096,deny)
 
    <para>
     If <productname>systemd</productname> is in use, some care must be taken
-    that IPC resources (shared memory and semaphores) are not prematurely
+    that IPC resources (including shared memory) are not prematurely
     removed by the operating system.  This is especially of concern when
     installing PostgreSQL from source.  Users of distribution packages of
     PostgreSQL are less likely to be affected, as
@@ -1137,11 +1137,12 @@ project.max-msg-ids=(priv,4096,deny)
    </para>
 
    <para>
-    A typical observed effect when this setting is on is that the semaphore
-    objects used by a PostgreSQL server are removed at apparently random
-    times, leading to the server crashing with log messages like
+    A typical observed effect when this setting is on is that shared memory
+    objects used for parallel query execution are removed at apparently random
+    times, leading to errors and warnings while attempting to open and remove
+    them, like
 <screen>
-LOG: semctl(1234567890, 0, IPC_RMID, ...) failed: Invalid argument
+WARNING:  could not remove shared memory segment "/PostgreSQL.1450751626": No such file or directory
 </screen>
     Different types of IPC objects (shared memory vs. semaphores, System V
     vs. POSIX) are treated slightly differently