Thread: Vacuuming the operating system documentation
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.
Attachment
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
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 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
On Sat, Jun 6, 2020 at 4:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 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
Magnus Hagander <magnus@hagander.net> writes:
> On Sat, Jun 6, 2020 at 4:41 PM Tom Lane <tgl@sss.pgh.pa.us> 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
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
On Sat, Jun 6, 2020 at 6:35 PM Peter Eisentraut <peter.eisentraut@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).
On Sun, Jun 7, 2020 at 4:39 AM Magnus Hagander <magnus@hagander.net> wrote:> > Oh they absolutely will. But most likely they will also use an older version of PostgreSQL because that's what their enterpriseproduct 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.
Attachment
Thomas Munro <thomas.munro@gmail.com> 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 <productname>PostgreSQL</productname>
is trying to create (4011376640 bytes in this example).
- This is more likely to happen if you have set <literal>shared_memory_type</literal>
+ This is only likely to happen if you have set <literal>shared_memory_type</literal>
to <literal>sysv</literal>. In that case, you
can try starting the server with a smaller-than-normal number of
buffers (<xref linkend="guc-shared-buffers"/>), or
@@ -1009,8 +1009,8 @@ psql: could not connect to server: No such file or directory
<prompt>$</prompt> <userinput>sysctl -w kernel.shmmax=17179869184</userinput>
<prompt>$</prompt> <userinput>sysctl -w kernel.shmall=4194304</userinput>
</screen>
- These settings can be preserved between reboots in
- the file <filename>/etc/sysctl.conf</filename>.
+ To make these settings persist over reboots, see
+ <filename>/etc/sysctl.conf</filename>.
</para>
</listitem>
@@ -1287,7 +1287,7 @@ default:\
</indexterm>
<para>
- The default virtual memory behavior is not
+ The default virtual memory behavior on Linux is not
optimal for <productname>PostgreSQL</productname>. Because of the
way that the kernel implements memory overcommit, the kernel might
terminate the <productname>PostgreSQL</productname> postmaster (the
On Sun, Jun 7, 2020 at 3:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.munro@gmail.com> 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=fsZXpObyojboUTN6BEOfUj4Q@mail.gmail.com
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
On Mon, Jun 8, 2020 at 3:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.munro@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.
Attachment
Thomas Munro <thomas.munro@gmail.com> writes:
> On Mon, Jun 8, 2020 at 3:00 AM Tom Lane <tgl@sss.pgh.pa.us> 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
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
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 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