Re: Vacuuming the operating system documentation
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Magnus Hagander <magnus@hagander.net>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-06-07T15:00:27Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > One more thing I spotted, post commit: the example symptom of > systemd's RemoveIPC feature trashing your cluster is an error from > semctl(), but that can't happen anymore on a standard build. Good point. > 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 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? regards, tom lane
Commits
-
Doc: Update example symptom of systemd misconfiguration.
- 682c28baf925 10.14 landed
- a35896c4b2a1 11.9 landed
- b944b1d1a9ac 12.4 landed
- a1c940cc5882 13.0 landed
- d094bf93014b 14.0 landed
-
Doc: Clean up references to obsolete OS versions.
- c8be915aa9fc 13.0 landed