Horton

Thread

Commits

  1. Doc: Update example symptom of systemd misconfiguration.

  2. Doc: Clean up references to obsolete OS versions.

  1. Vacuuming the operating system documentation

    Thomas Munro <thomas.munro@gmail.com> — 2020-06-06T04:57:20Z

    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.

  2. Re: Vacuuming the operating system documentation

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2020-06-06T07:58:43Z

    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

  3. Re: Vacuuming the operating system documentation

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-06-06T14:41:17Z

    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

  4. Re: Vacuuming the operating system documentation

    Magnus Hagander <magnus@hagander.net> — 2020-06-06T14:57:24Z

    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

  5. Re: Vacuuming the operating system documentation

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-06-06T15:14:06Z

    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

  6. Re: Vacuuming the operating system documentation

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2020-06-06T16:35:29Z

    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

  7. Re: Vacuuming the operating system documentation

    Magnus Hagander <magnus@hagander.net> — 2020-06-06T16:38:52Z

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

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

  8. Re: Vacuuming the operating system documentation

    Thomas Munro <thomas.munro@gmail.com> — 2020-06-07T02:52:01Z

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

  9. Re: Vacuuming the operating system documentation

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-06-07T03:42:50Z

    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

  10. Re: Vacuuming the operating system documentation

    Thomas Munro <thomas.munro@gmail.com> — 2020-06-07T11:03:57Z

    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

  11. Re: Vacuuming the operating system documentation

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-06-07T15:00:27Z

    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

  12. Re: Vacuuming the operating system documentation

    Thomas Munro <thomas.munro@gmail.com> — 2020-06-07T23:54:58Z

    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.

  13. Re: Vacuuming the operating system documentation

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-06-08T00:03:09Z

    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

  14. Re: Vacuuming the operating system documentation

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2020-06-08T05:44:06Z

    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

  15. Re: Vacuuming the operating system documentation

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-06-08T13:51:00Z

    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