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
This commit is contained in:
Thomas Munro 2020-06-08 13:20:46 +12:00
parent 10ffe0fa72
commit a1c940cc58

View File

@ -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