Re: Back-patch use of unnamed POSIX semaphores for Linux?

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 12/7/16 9:28 PM, Alex Hunsaker wrote:
>> Hrm, the following incantation seems to break for me on a fresh Fedora
>> 25 system:
>> 1) As root su to $USER and start postgres.
>> 2) ssh in as $USER and then logout
>> 3) # psql localhost
>>
>> FATAL: semctl(4980742, 3, SETVAL, 0) failed: Invalid argument
>> LOG: server process (PID 14569) exited with exit code 1

> Yeah, the way to trigger this is to run the postgres server not in a
> "session", then log in interactively as that same user, thus creating a
> session, and then logging out from that session, thus completely logging
> out that user from all sessions.

> (Thus, the way to trigger the KillUserProcesses behavior is quite the
> opposite, because that only happens if you have the postgres server
> running in a session.)

Ah-hah, thanks for the insight. I can now reproduce it, and I confirm
that aside from removing the semaphores, our POSIX shmem segment(s)
are removed from /dev/shm. They presumably still are attached to whatever
processes have them mapped already, but this behavior is going to break
DSM usage in any case. (The SysV shm segment does survive, presumably
because systemd notices its positive attach count.)

So I now agree that getting out from under SysV semaphores isn't going to
fix our problems with systemd ... at least, not unless we migrate *to*
not away from SysV shared memory for DSM. Even then, we'd have to be
careful that standard usage patterns keep every DSM segment continually
attached to at least one process. Dunno how practical that is. And it
blows chunks in the goal of not being constrained by SHMMAX.

Oh well.

regards, tom lane