On Mon, Jun 8, 2020 at 3:00 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.mu...@gmail.com> writes: > > Not sure > > what to put in its place... I guess the remaining symptoms would be > > (1) the little "interlock" shmem segment is unregistered, which is > > probably symptom-free (until you start a second postmaster in the same > > pgdata), and (2) POSIX shm objects getting unlinked underneath a > > parallel query. > > (1) would be very scary, because the "symptom" would be "second postmaster > successfully starts and trashes your database". But our previous > discussion found that that won't happen, because systemd notices the > segment's positive nattch count. Unfortunately it seems there's nothing > equivalent for POSIX shmem, so (2) is possible. See
Ah, I see. Ok, I propose we update the example symptom to (2), and back-patch to 10. See attached. > https://www.postgresql.org/message-id/5915.1481218827%40sss.pgh.pa.us > > Relevant to the current discussion: this creates a possible positive > reason for setting dynamic_shared_memory_type to "sysv", namely if it's > the best available way to get around RemoveIPC in a particular situation. > Should we document that? Doesn't seem worth the trouble, especially since the real solution is to tell systemd to back off by one of the two methods described. Also, I guess there's a moment between shmget() and shmat() when a newborn SysV DSM segment has nattch == 0.
From 5005e5b143bdce05e4d8c9a5598a2114bfe7da2f Mon Sep 17 00:00:00 2001 From: Thomas Munro <thomas.mu...@gmail.com> Date: Mon, 8 Jun 2020 11:31:28 +1200 Subject: [PATCH] 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. Discussion: https://postgr.es/m/CA%2BhUKGLmJUSwybaPQv39rB8ABpqJq84im2UjZvyUY4feYhpWMw%40mail.gmail.com --- doc/src/sgml/runtime.sgml | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 1b2012d34a..a57c68ce61 100644 --- a/doc/src/sgml/runtime.sgml +++ b/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 attemping 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 -- 2.20.1
