Re: Vacuuming the operating system documentation

[Tom Lane]

Peter Eisentraut  writes:
> On 2020-06-07 17:00, Tom Lane wrote:
>> 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?

> It sounds like both shared_memory_type and dynamic_shared_memory_type 
> ought to default to "sysv" on Linux.

Per the discussion in the older thread, that would only fix things if we
held at least one attach count constantly on every shared segment.  IIUC,
that's not guaranteed for DSAs.  So changing dynamic_shared_memory_type
would reduce the risk but not really fix anything.

For the primary shm segment, we don't (without EXEC_BACKEND) really
care if somebody unlinks the file prematurely, since backends inherit
the mapping via fork.  Hence, no need to change shared_memory_type.

regards, tom lane

Re: Vacuuming the operating system documentation

[Peter Eisentraut]

On 2020-06-07 17:00, Tom Lane wrote:

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?


It sounds like both shared_memory_type and dynamic_shared_memory_type 
ought to default to "sysv" on Linux.


--
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Vacuuming the operating system documentation

[Tom Lane]

Thomas Munro  writes:
> On Mon, Jun 8, 2020 at 3:00 AM Tom Lane  wrote:
>> ... 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.

+1, except s/attemping/attempting/

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

Agreed.

regards, tom lane

Re: Vacuuming the operating system documentation

[Thomas Munro]

On Mon, Jun 8, 2020 at 3:00 AM Tom Lane  wrote:
> Thomas Munro  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 
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)
 

 If systemd 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)

 

-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
 
-LOG: semctl(1234567890, 0, IPC_RMID, ...) failed: Invalid argument
+WARNING:  could not remove shared memory segment "/PostgreSQL.1450751626": No such file or directory
 
 Different types of IPC objects (shared memory vs. semaphores, System V
 vs. POSIX) are treated slightly differently
-- 
2.20.1

Re: Vacuuming the operating system documentation

[Tom Lane]

Thomas Munro  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

Re: Vacuuming the operating system documentation

[Thomas Munro]

On Sun, Jun 7, 2020 at 3:42 PM Tom Lane  wrote:
> Thomas Munro  writes:
> > Yeah, I wasn't planning on changing anything in backbranches.  It
> > sounds like we're OK with doing this for 13.  Here's a version with a
> > few more changes:
>
> Looks pretty good to me.  I attach a delta patch with a few more
> proposed adjustments.  Notably, I made the wording about /etc/sysctl.conf
> for Linux match that for other OSes, except I said "see" not
> "modify" because (at least on my Red Hat based installations)
> the comments in /etc/sysctl.conf direct you to modify various
> sub-files.

Thanks.  Pushed.

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.  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.  That's probably what this build farm animal was
telling me:

https://www.postgresql.org/message-id/CA+hUKG+t40GoUczAhQsRhxWeS=fszxpobyojboutn6beofu...@mail.gmail.com

Re: Vacuuming the operating system documentation

[Tom Lane]

Thomas Munro  writes:
> Yeah, I wasn't planning on changing anything in backbranches.  It
> sounds like we're OK with doing this for 13.  Here's a version with a
> few more changes:

Looks pretty good to me.  I attach a delta patch with a few more
proposed adjustments.  Notably, I made the wording about /etc/sysctl.conf
for Linux match that for other OSes, except I said "see" not
"modify" because (at least on my Red Hat based installations)
the comments in /etc/sysctl.conf direct you to modify various
sub-files.

> ... I am aware of one modern kernel that ships
> pre-built without SysV IPC: Android, but apparently this stuff is also
> missing from its libc so you won't get this far.

Yeah, ISTR some prior discussion about that on our lists.
If anyone's trying to run PG on their phone, they probably
do not need help from these docs.

regards, tom lane

diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 927f062abe..1b2012d34a 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -539,7 +539,7 @@ DETAIL:  Failed system call was shmget(key=5440001, size=4011376640, 03600).
  probably means your kernel's limit on the size of shared memory is
  smaller than the work area PostgreSQL
  is trying to create (4011376640 bytes in this example).
- This is more likely to happen if you have set shared_memory_type
+ This is only likely to happen if you have set shared_memory_type
  to sysv.  In that case, you
  can try starting the server with a smaller-than-normal number of
  buffers (), or
@@ -1009,8 +1009,8 @@ psql: could not connect to server: No such file or directory
 $ sysctl -w kernel.shmmax=17179869184
 $ sysctl -w kernel.shmall=4194304
 
-These settings can be preserved between reboots in
-the file /etc/sysctl.conf.
+To make these settings persist over reboots, see
+/etc/sysctl.conf.

 
   
@@ -1287,7 +1287,7 @@ default:\

 

-The default virtual memory behavior is not
+The default virtual memory behavior on Linux is not
 optimal for PostgreSQL. Because of the
 way that the kernel implements memory overcommit, the kernel might
 terminate the PostgreSQL postmaster (the

Re: Vacuuming the operating system documentation

[Thomas Munro]

On Sun, Jun 7, 2020 at 4:39 AM Magnus Hagander  wrote:>
> Oh they absolutely will. But most likely they will also use an older version 
> of PostgreSQL because that's what their enterprise product supports. And 
> we're not talking about removing the documentation from the old version (I'm 
> assuming).

Yeah, I wasn't planning on changing anything in backbranches.  It
sounds like we're OK with doing this for 13.  Here's a version with a
few more changes:

 * Drop mention of Linux oom_adj, per discussion.
 * Add paragraphs to each OS to point out what we actually expect you
to need to change (ie mostly nothing).
 * Drop mention of PG 9.2's requirements for more SysV shmem.  It made
sense to have that in there while versions with both behaviours were
still in circulation and you could have been looking at the wrong
version's manual, but that's stuff you can find in old release notes
if you're a historian.
 * Drop the paragraph that tells you what Linux's default SHMMAX is:
that has been wrong since 3.16.  The default is now sky high, a bit
under ULONG_MAX.
 * Drop the alternative way to set SHMMAX etc via /proc on Linux.
There's hardly any reason to do it at all, so describing two ways is
just wasting pixels.
 * Drop some more comments about ancient macOS.
 * Adjust the text that discusses adjusting shared_buffers if you
can't acquire enough SysV shmem, because that only makes sense if
shared_memory_type=sysv.
 * Point out that NetBSD's kern.ipc.shm_use_phys only applies to SysV
memory, as done for FreeBSD in the previous version.  I hadn't noticed
that NetBSD has that too, and I peeked at the source to check that
they only use that for SysV memory too.
 * Drop the text about recognising and reconfiguring kernels that were
built without SysV support; that's advice from another age.  Regular
users don't configure and build kernels, and those that do that don't
need these hints.  I am aware of one modern kernel that ships
pre-built without SysV IPC: Android, but apparently this stuff is also
missing from its libc so you won't get this far.
From 209d9fbee43a4043ac6fe657f804cc396944e6d7 Mon Sep 17 00:00:00 2001
From: Thomas Munro 
Date: Sat, 6 Jun 2020 15:20:14 +1200
Subject: [PATCH v2] doc: Clean up references to obsolete OS versions.

Remove obsolete instructions for old operating system versions, and
update the text to reflect the defaults on modern systems.

Reviewed-by: Peter Eisentraut 
Reviewed-by: Tom Lane 
Reviewed-by: Magnus Hagander 
Discussion: https://postgr.es/m/CA%2BhUKGLmJUSwybaPQv39rB8ABpqJq84im2UjZvyUY4feYhpWMw%40mail.gmail.com
---
 doc/src/sgml/runtime.sgml | 275 +-
 1 file changed, 62 insertions(+), 213 deletions(-)

diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index a8bb85e6f5..927f062abe 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -538,12 +538,12 @@ DETAIL:  Failed system call was shmget(key=5440001, size=4011376640, 03600).
 
  probably means your kernel's limit on the size of shared memory is
  smaller than the work area PostgreSQL
- is trying to create (4011376640 bytes in this example). Or it could
- mean that you do not have System-V-style shared memory support
- configured into your kernel at all. As a temporary workaround, you
+ is trying to create (4011376640 bytes in this example).
+ This is more likely to happen if you have set shared_memory_type
+ to sysv.  In that case, you
  can try starting the server with a smaller-than-normal number of
- buffers (). You will eventually want
- to reconfigure your kernel to increase the allowed shared memory
+ buffers (), or
+ reconfigure your kernel to increase the allowed shared memory
  size. You might also see this message when trying to start multiple
  servers on the same machine, if their total space requested
  exceeds the kernel limit.
@@ -565,13 +565,6 @@ DETAIL:  Failed system call was semget(5440126, 17, 03600).
  increase the kernel limit.
 
 
-
- If you get an illegal system call error, it is likely that
- shared memory or semaphores are not supported in your kernel at
- all. In that case your only option is to reconfigure the kernel to
- enable these features.
-
-
 
  Details about configuring System V
  IPC facilities are given in .
@@ -662,14 +655,6 @@ psql: could not connect to server: No such file or directory
 these features and is not discussed here.

 
-   
-The complete lack of these facilities is usually manifested by an
-Illegal system call error upon server
-start.  In that case there is no alternative but to reconfigure your
-kernel.  PostgreSQL won't work without them.
-This situation is rare, however, among modern operating systems.
-   
-

 By default, PostgreSQL allocates
 a very small amount of System V shared memory, as well as a much larger
@@ -683,15 +668,6 @@ psql: could not 

Re: Vacuuming the operating system documentation

[Magnus Hagander]

On Sat, Jun 6, 2020 at 6:35 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:

> On 2020-06-06 17:14, Tom Lane wrote:
> >> Let's hope PG13 isn't that late -- the end of Extended Lifecycle
> Support is
> >> June 30, 2024 for RHEL 6. (It*enters*  ELS around the time of pg 13).
> > ELS basically means that they aren't going to take down the existing
> > website information about RHEL6 just yet.
>
> Hmm, we removed support for RHEL 5 in PG 13, partially based on the
> information that ELS for RHEL 5 ends in November 2020.  It appears we
> have misinterpreted that and we can trim the trailing edge more
> aggressively.
>
> Anyway, this is only a documentation patch.  Surely no one will doing
> their very first install of Postgres on an unconfigured RHEL 6 this year.
>

Oh they absolutely will. But most likely they will also use an older
version of PostgreSQL because that's what their enterprise product
supports. And we're not talking about removing the documentation from the
old version (I'm assuming).

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

Re: Vacuuming the operating system documentation

[Peter Eisentraut]

On 2020-06-06 17:14, Tom Lane wrote:

Let's hope PG13 isn't that late -- the end of Extended Lifecycle Support is
June 30, 2024 for RHEL 6. (It*enters*  ELS around the time of pg 13).

ELS basically means that they aren't going to take down the existing
website information about RHEL6 just yet.


Hmm, we removed support for RHEL 5 in PG 13, partially based on the 
information that ELS for RHEL 5 ends in November 2020.  It appears we 
have misinterpreted that and we can trim the trailing edge more 
aggressively.


Anyway, this is only a documentation patch.  Surely no one will doing 
their very first install of Postgres on an unconfigured RHEL 6 this year.


--
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Vacuuming the operating system documentation

[Tom Lane]

Magnus Hagander  writes:
> On Sat, Jun 6, 2020 at 4:41 PM Tom Lane  wrote:
>> So I concur with dropping all this stuff, and while we're at it I'd vote
>> for getting rid of the oom_adj para.  RHEL6 will be fully EOL around the
>> time PG13 comes out, so I don't believe anyone's making brand new installs
>> there either.

> Let's hope PG13 isn't that late -- the end of Extended Lifecycle Support is
> June 30, 2024 for RHEL 6. (It *enters* ELS around the time of pg 13).

ELS basically means that they aren't going to take down the existing
website information about RHEL6 just yet.  I quote from the EOL notice
I got last December:

This is the one year retirement notice for Red Hat Enterprise Linux 6
Maintenance Support 2 (Product Retirement) Phase. This notification
applies only to those customers subscribed to minor releases for Red
Hat Enterprise Linux 6.

In accordance with the Red Hat Enterprise Linux Errata Support Policy,
Red Hat Enterprise Linux 6 will be retired as of November 30, 2020 and
enter Extended Life Phase which means users will receive the below
support.

? Limited technical support for existing Red Hat Enterprise Linux 6
  deployments.
? Previously released bug fixes (RHBAs), security errata (RHSAs), and
  product enhancements (RHEAs).
? Red Hat Knowledgebase and other content (white papers, reference 
  architectures, etc.) found in the Red Hat Customer Portal.
? Red Hat Enterprise Linux 6 documentation.

There won't be any new bug or security fixes after December; the above is
only saying that existing updates will still be available to download.
(I'm not sure what "limited technical support" really means, but I bet
it involves forking over additional per-incident money.)

>From our own perspective, we no longer have the ability to support PG
on RHEL6 anyway.  I see no RHEL6 machines in the buildfarm, and my own
installation is on a disk that's not even connected to anything anymore.
So we might as well stop giving the impression that it's supported.

regards, tom lane

Re: Vacuuming the operating system documentation

[Magnus Hagander]

On Sat, Jun 6, 2020 at 4:41 PM Tom Lane  wrote:

> Peter Eisentraut  writes:
> > On 2020-06-06 06:57, Thomas Munro wrote:
> >> We're carrying a bunch of obsolete and in one case insecure advice on
> >> kernel settings.  Here's an attempt to clean some of that up.
>
> > These changes seem sensible to me.
>
> +1
>

+1 as well.


>> HP-UX:
> >> * Drop advice for v10.  11.x came out 23 years ago.
>
> > We still have a version 10 in the build farm. :)
>
> Yeah, but I don't need advice on installing PG on that ;-).  In general,
> I think the filter rule could be: is it likely that someone would try to
> install PG 13-or-later from scratch (with no pre-existing installation)
> on this OS version?  If there is a pre-existing install, they'll already
> have dealt with any kernel configuration issues.
>
> So I concur with dropping all this stuff, and while we're at it I'd vote
> for getting rid of the oom_adj para.  RHEL6 will be fully EOL around the
> time PG13 comes out, so I don't believe anyone's making brand new installs
> there either.
>
>
Let's hope PG13 isn't that late -- the end of Extended Lifecycle Support is
June 30, 2024 for RHEL 6. (It *enters* ELS around the time of pg 13).

And yes, given that, you'd be surprised how many people make brand new
installs on that. That said, they *shoudln't*, so I'm fine with dropping
the instructions for those as well. With luck it might encourage some
people to realize it's a bad idea...

//Magnus

Re: Vacuuming the operating system documentation

[Tom Lane]

Peter Eisentraut  writes:
> On 2020-06-06 06:57, Thomas Munro wrote:
>> We're carrying a bunch of obsolete and in one case insecure advice on
>> kernel settings.  Here's an attempt to clean some of that up.

> These changes seem sensible to me.

+1

>> HP-UX:
>> * Drop advice for v10.  11.x came out 23 years ago.

> We still have a version 10 in the build farm. :)

Yeah, but I don't need advice on installing PG on that ;-).  In general,
I think the filter rule could be: is it likely that someone would try to
install PG 13-or-later from scratch (with no pre-existing installation)
on this OS version?  If there is a pre-existing install, they'll already
have dealt with any kernel configuration issues.

So I concur with dropping all this stuff, and while we're at it I'd vote
for getting rid of the oom_adj para.  RHEL6 will be fully EOL around the
time PG13 comes out, so I don't believe anyone's making brand new installs
there either.

regards, tom lane

Re: Vacuuming the operating system documentation

[Peter Eisentraut]

On 2020-06-06 06:57, Thomas Munro wrote:

We're carrying a bunch of obsolete and in one case insecure advice on
kernel settings.  Here's an attempt to clean some of that up.


These changes seem sensible to me.


HP-UX:
  * Drop advice for v10.  11.x came out 23 years ago.


We still have a version 10 in the build farm. :)


It's a bit inconsistent that we bother to explain the SysV shmem
sysctls on some systems but not others, just because once upon a time
it was necessary to tweak them on some systems and not others due to
defaults.  You shouldn't need that anywhere now IIUC, unless you run a
lot of clusters or use shared_memory_type=sysv.  I'm not proposing to
add it where it's missing, as I don't have the information and I doubt
it's really useful anyway; you can find that stuff elsewhere if you
really need it.


When this was a serious hurdle on the olden days, we added as much 
information as possible.  I agree we can trim it now or let it age out.


--
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Vacuuming the operating system documentation

[Thomas Munro]

Hi,

We're carrying a bunch of obsolete and in one case insecure advice on
kernel settings.  Here's an attempt to clean some of that up.

Linux:
 * Drop reference to ancient systems that didn't have a sysctl command.
 * Drop references to Linux before 2.6.
 * I was tempted to remove the reference to oom_adj, which was
apparently deprecated from 2.6.36, but that's probably recent enough
to keep (RHEL6 may outlive humanity).

macOS:
 * Drop reference to 10.2 and 10.3 systems.  That's 15-16 years ago.
Even the ancient PPC systems in the build farm run 10.4+.

FreeBSD:
 * Drop insecure and outdated jail instructions.  I moved the
pre-FreeBSD 11 behaviour into a brief note in parentheses, because
FreeBSD 11 is the oldest release of that OS that is still in support.
In that parenthetical note, I dropped the reference to port numbers
and UIDs in shmem keys since we now use pgdata inode numbers instead.
 * Drop SysV semaphore instruction.  We switched to POSIX on this
platform in PostgreSQL 10, and we don't bother to give the redundant
instructions about semaphores for Linux so we might as well drop this
noise for FreeBSD too.
 * Clarify that kern.ipc.shm_use_phys only has a useful effect if
shared_memory_type=sysv, which is not the default.
 * Drop some stuff about pre-4.0 systems.  That was 20 years ago.

NetBSD:
 * Drop reference to pre-5.0 systems.  That was 11 years ago.  Maybe
someone wants to argue with me on this one?

OpenBSD:
 * Drop instruction on recompiling the kernel on pre-3.3 systems.
That was 17 years ago.

Solaris/illumos:
 * Drop instructions on Solaris 6-9 systems.  10 came out 15 years
ago, 9 was fully desupported 6 years ago.  The last person to mention
Solaris 9 on the mailing list was ... me.  That machine had cobwebs
even then.
 * Drop reference to OpenSolaris, which was cancelled ten years ago;
the surviving project goes by illumos, so use that name.

AIX:
 * Drop reference to 5.1, since there is no way older systems than
that are going to be running new PostgreSQL releases.  5.1 itself was
desupported by IBM 14 years ago.

HP-UX:
 * Drop advice for v10.  11.x came out 23 years ago.

It's a bit inconsistent that we bother to explain the SysV shmem
sysctls on some systems but not others, just because once upon a time
it was necessary to tweak them on some systems and not others due to
defaults.  You shouldn't need that anywhere now IIUC, unless you run a
lot of clusters or use shared_memory_type=sysv.  I'm not proposing to
add it where it's missing, as I don't have the information and I doubt
it's really useful anyway; you can find that stuff elsewhere if you
really need it.
From be61fe032a2b8ac3b6130c1f7a38c918d9423ec8 Mon Sep 17 00:00:00 2001
From: Thomas Munro 
Date: Sat, 6 Jun 2020 15:20:14 +1200
Subject: [PATCH] doc: Clean up references to obsolete OS versions.

Modernize the documentation to remove insecure and/or obsolete
instructions about old operating systems.
---
 doc/src/sgml/runtime.sgml | 152 +-
 1 file changed, 19 insertions(+), 133 deletions(-)

diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index a8bb85e6f5..c0d1860bf2 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -872,7 +872,7 @@ psql: could not connect to server: No such file or directory
   
   

-At least as of version 5.1, it should not be necessary to do
+It should not be necessary to do
 any special configuration for such parameters as
 SHMMAX, as it appears this is configured to
 allow all memory to be used as shared memory.  That is the
@@ -907,41 +907,24 @@ psql: could not connect to server: No such file or directory
 /etc/sysctl.conf.

 
-   
-These semaphore-related settings are read-only as far as
-sysctl is concerned, but can be set in
-/boot/loader.conf:
-
-kern.ipc.semmni=256
-kern.ipc.semmns=512
-
-After modifying that file, a reboot is required for the new
-settings to take effect.
-   
-
-   
-You might also want to configure your kernel to lock System V shared
+  
+If you have set shared_memory_type to
+sysv (not the default, see ),
+you might also want to configure your kernel to lock System V shared
 memory into RAM and prevent it from being paged out to swap.
 This can be accomplished using the sysctl
 setting kern.ipc.shm_use_phys.

 

-If running in FreeBSD jails by enabling sysctl's
-security.jail.sysvipc_allowed, postmasters
-running in different jails should be run by different operating system
-users.  This improves security because it prevents non-root users
-from interfering with shared memory or semaphores in different jails,
-and it allows the PostgreSQL IPC cleanup code to function properly.
-(In FreeBSD 6.0 and later the IPC cleanup code does not properly