Re: Vacuuming the operating system documentation

On Mon, Jun 8, 2020 at 3:00 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)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.