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.
Attachments:
0001-doc-Clean-up-references-to-obsolete-OS-versions.patchtext/x-patch; charset=US-ASCII; name=0001-doc-Clean-up-references-to-obsolete-OS-versions.patchDownload
From be61fe032a2b8ac3b6130c1f7a38c918d9423ec8 Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
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
</term>
<listitem>
<para>
- 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
<varname>SHMMAX</varname>, 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
<filename>/etc/sysctl.conf</filename>.
</para>
- <para>
- These semaphore-related settings are read-only as far as
- <command>sysctl</command> is concerned, but can be set in
- <filename>/boot/loader.conf</filename>:
-<programlisting>
-kern.ipc.semmni=256
-kern.ipc.semmns=512
-</programlisting>
- After modifying that file, a reboot is required for the new
- settings to take effect.
- </para>
-
- <para>
- You might also want to configure your kernel to lock System V shared
+ <para>
+ If you have set <literal>shared_memory_type</literal> to
+ <literal>sysv</literal> (not the default, see <xref linkend="sysvipc"/>),
+ 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 <command>sysctl</command>
setting <literal>kern.ipc.shm_use_phys</literal>.
</para>
<para>
- If running in FreeBSD jails by enabling <application>sysctl</application>'s
- <literal>security.jail.sysvipc_allowed</literal>, <application>postmaster</application>s
- 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 detect
- processes in other jails, preventing the running of postmasters on the
- same port in different jails.)
+ If running in a FreeBSD jail, you should set its
+ <literal>sysvshm</literal> parameter to <literal>new</literal>, so that
+ it has its own separate System V shared memory namespace.
+ (Before FreeBSD 11.0, it was necessary to enable shared access to
+ the host's IPC namespace from jails, and take measures to avoid
+ collisions.)
</para>
- <para>
- <systemitem class="osname">FreeBSD</systemitem> versions before 4.0 work like
- old <systemitem class="osname">OpenBSD</systemitem> (see below).
- </para>
</listitem>
</varlistentry>
@@ -974,13 +957,6 @@ kern.ipc.semmns=512
This can be accomplished using the <command>sysctl</command>
setting <literal>kern.ipc.shm_use_phys</literal>.
</para>
-
- <para>
- <systemitem class="osname">NetBSD</systemitem> versions before 5.0
- work like old <systemitem class="osname">OpenBSD</systemitem>
- (see below), except that kernel parameters should be set with the
- keyword <literal>options</literal> not <literal>option</literal>.
- </para>
</listitem>
</varlistentry>
@@ -990,7 +966,7 @@ kern.ipc.semmns=512
</term>
<listitem>
<para>
- In <systemitem class="osname">OpenBSD</systemitem> 3.3 and later,
+ In <systemitem class="osname">OpenBSD</systemitem>,
IPC parameters can be adjusted using <command>sysctl</command>,
for example:
<screen>
@@ -1008,25 +984,6 @@ kern.ipc.semmns=512
for these are uncomfortably small.
</para>
- <para>
- In older <systemitem class="osname">OpenBSD</systemitem> versions,
- you will need to build a custom kernel to change the IPC parameters.
- Make sure that the options <varname>SYSVSHM</varname>
- and <varname>SYSVSEM</varname> are enabled, too. (They are by
- default.) The following shows an example of how to set the various
- parameters in the kernel configuration file:
-<programlisting>
-option SYSVSHM
-option SHMMAXPGS=4096
-option SHMSEG=256
-
-option SYSVSEM
-option SEMMNI=256
-option SEMMNS=512
-option SEMMNU=256
-</programlisting>
- </para>
-
</listitem>
</varlistentry>
@@ -1037,9 +994,6 @@ option SEMMNU=256
<listitem>
<para>
The default settings tend to suffice for normal installations.
- On <productname>HP-UX</productname> 10, the factory default for
- <varname>SEMMNS</varname> is 128, which might be too low for larger
- database sites.
</para>
<para>
<acronym>IPC</acronym> parameters can be set in the <application>System
@@ -1078,9 +1032,7 @@ option SEMMNU=256
</para>
<para>
- Ancient distributions might not have the <command>sysctl</command> program,
- but equivalent changes can be made by manipulating the
- <filename>/proc</filename> file system:
+ Alternatively, the <filename>/proc</filename> file system can be used:
<screen>
<prompt>$</prompt> <userinput>echo 17179869184 >/proc/sys/kernel/shmmax</userinput>
<prompt>$</prompt> <userinput>echo 4194304 >/proc/sys/kernel/shmall</userinput>
@@ -1134,65 +1086,15 @@ kern.sysv.shmall=1024
kept across reboots.
</para>
- <para>
- The file <filename>/etc/sysctl.conf</filename> is only honored in macOS
- 10.3.9 and later. If you are running a previous 10.3.x release,
- you must edit the file <filename>/etc/rc</filename>
- and change the values in the following commands:
-<programlisting>
-sysctl -w kern.sysv.shmmax
-sysctl -w kern.sysv.shmmin
-sysctl -w kern.sysv.shmmni
-sysctl -w kern.sysv.shmseg
-sysctl -w kern.sysv.shmall
-</programlisting>
- Note that
- <filename>/etc/rc</filename> is usually overwritten by macOS system updates,
- so you should expect to have to redo these edits after each update.
- </para>
-
- <para>
- In macOS 10.2 and earlier, instead edit these commands in the file
- <filename>/System/Library/StartupItems/SystemTuning/SystemTuning</filename>.
- </para>
- </listitem>
- </varlistentry>
-
-
- <varlistentry>
- <term><systemitem class="osname">Solaris</systemitem> 2.6 to 2.9 (Solaris
- 6 to Solaris 9)
- <indexterm><primary>Solaris</primary><secondary>IPC configuration</secondary></indexterm>
- </term>
- <listitem>
- <para>
- The relevant settings can be changed in
- <filename>/etc/system</filename>, for example:
-<programlisting>
-set shmsys:shminfo_shmmax=0x2000000
-set shmsys:shminfo_shmmin=1
-set shmsys:shminfo_shmmni=256
-set shmsys:shminfo_shmseg=256
-
-set semsys:seminfo_semmap=256
-set semsys:seminfo_semmni=512
-set semsys:seminfo_semmns=512
-set semsys:seminfo_semmsl=32
-</programlisting>
- You need to reboot for the changes to take effect. See also
- <ulink url="http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html"></ulink>
- for information on shared memory under older versions of Solaris.
- </para>
</listitem>
</varlistentry>
<varlistentry>
- <term><systemitem class="osname">Solaris</systemitem> 2.10 (Solaris
- 10) and later</term>
- <term><systemitem class="osname">OpenSolaris</systemitem></term>
+ <term><systemitem class="osname">Solaris</systemitem></term>
+ <term><systemitem class="osname">illumos</systemitem></term>
<listitem>
<para>
- In Solaris 10 and later, and OpenSolaris, the default shared memory and
+ In Solaris 10 and later, and illumos, the default shared memory and
semaphore settings are good enough for most
<productname>PostgreSQL</productname> applications. Solaris now defaults
to a <varname>SHMMAX</varname> of one-quarter of system <acronym>RAM</acronym>.
@@ -1415,7 +1317,7 @@ default:\
</indexterm>
<para>
- In Linux 2.4 and later, the default virtual memory behavior is not
+ The default virtual memory behavior 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
@@ -1462,7 +1364,7 @@ Out of Memory: Killed process 12345 (postgres).
</para>
<para>
- On Linux 2.6 and later, it is possible to modify the
+ It is possible to modify the
kernel's behavior so that it will not <quote>overcommit</quote> memory.
Although this setting will not prevent the <ulink
url="https://lwn.net/Articles/104179/">OOM killer</ulink> from being invoked
@@ -1508,28 +1410,12 @@ export PG_OOM_ADJUST_VALUE=0
</para>
<para>
- Older Linux kernels do not offer <filename>/proc/self/oom_score_adj</filename>,
+ Very old Linux kernels do not offer <filename>/proc/self/oom_score_adj</filename>,
but may have a previous version of the same functionality called
<filename>/proc/self/oom_adj</filename>. This works the same except the disable
value is <literal>-17</literal> not <literal>-1000</literal>.
</para>
- <note>
- <para>
- Some vendors' Linux 2.4 kernels are reported to have early versions
- of the 2.6 overcommit <command>sysctl</command> parameter. However, setting
- <literal>vm.overcommit_memory</literal> to 2
- on a 2.4 kernel that does not have the relevant code will make
- things worse, not better. It is recommended that you inspect
- the actual kernel source code (see the function
- <function>vm_enough_memory</function> in the file <filename>mm/mmap.c</filename>)
- to verify what is supported in your kernel before you try this in a 2.4
- installation. The presence of the <filename>overcommit-accounting</filename>
- documentation file should <emphasis>not</emphasis> be taken as evidence that the
- feature is there. If in any doubt, consult a kernel expert or your
- kernel vendor.
- </para>
- </note>
</sect2>
<sect2 id="linux-huge-pages">
--
2.20.1
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).
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
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.
Attachments:
v2-0001-doc-Clean-up-references-to-obsolete-OS-versions.patchtext/x-patch; charset=US-ASCII; name=v2-0001-doc-Clean-up-references-to-obsolete-OS-versions.patchDownload
From 209d9fbee43a4043ac6fe657f804cc396944e6d7 Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
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 <peter.eisentraut@2ndquadrant.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Reviewed-by: Magnus Hagander <magnus@hagander.net>
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).
</screen>
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). 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 <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"/>). You will eventually want
- to reconfigure your kernel to increase the allowed shared memory
+ buffers (<xref linkend="guc-shared-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.
</para>
- <para>
- If you get an <quote>illegal system call</quote> 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.
- </para>
-
<para>
Details about configuring <systemitem class="osname">System V</systemitem>
<acronym>IPC</acronym> facilities are given in <xref linkend="sysvipc"/>.
@@ -662,14 +655,6 @@ psql: could not connect to server: No such file or directory
these features and is not discussed here.
</para>
- <para>
- The complete lack of these facilities is usually manifested by an
- <quote><errorname>Illegal system call</errorname></quote> error upon server
- start. In that case there is no alternative but to reconfigure your
- kernel. <productname>PostgreSQL</productname> won't work without them.
- This situation is rare, however, among modern operating systems.
- </para>
-
<para>
By default, <productname>PostgreSQL</productname> allocates
a very small amount of System V shared memory, as well as a much larger
@@ -683,15 +668,6 @@ psql: could not connect to server: No such file or directory
platforms use System V semaphores.
</para>
- <note>
- <para>
- Prior to <productname>PostgreSQL</productname> 9.3, only System V shared memory
- was used, so the amount of System V shared memory required to start the
- server was much larger. If you are running an older version of the
- server, please consult the documentation for your server version.
- </para>
- </note>
-
<para>
System V <acronym>IPC</acronym> features are typically constrained by
system-wide allocation limits.
@@ -872,7 +848,7 @@ psql: could not connect to server: No such file or directory
</term>
<listitem>
<para>
- 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
<varname>SHMMAX</varname>, as it appears this is configured to
allow all memory to be used as shared memory. That is the
@@ -894,6 +870,12 @@ psql: could not connect to server: No such file or directory
<indexterm><primary>FreeBSD</primary><secondary>IPC configuration</secondary></indexterm>
</term>
<listitem>
+ <para>
+ The default shared memory settings are usually good enough, unless
+ you have set <literal>shared_memory_type</literal> to <literal>sysv</literal>.
+ System V semaphores are not used on this platform.
+ </para>
+
<para>
The default IPC settings can be changed using
the <command>sysctl</command> or
@@ -908,40 +890,22 @@ psql: could not connect to server: No such file or directory
</para>
<para>
- These semaphore-related settings are read-only as far as
- <command>sysctl</command> is concerned, but can be set in
- <filename>/boot/loader.conf</filename>:
-<programlisting>
-kern.ipc.semmni=256
-kern.ipc.semmns=512
-</programlisting>
- After modifying that file, a reboot is required for the new
- settings to take effect.
- </para>
-
- <para>
- 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 <command>sysctl</command>
+ If you have set <literal>shared_memory_type</literal> to
+ <literal>sysv</literal>, 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 <command>sysctl</command>
setting <literal>kern.ipc.shm_use_phys</literal>.
</para>
<para>
- If running in FreeBSD jails by enabling <application>sysctl</application>'s
- <literal>security.jail.sysvipc_allowed</literal>, <application>postmaster</application>s
- 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 detect
- processes in other jails, preventing the running of postmasters on the
- same port in different jails.)
+ If running in a FreeBSD jail, you should set its
+ <literal>sysvshm</literal> parameter to <literal>new</literal>, so that
+ it has its own separate System V shared memory namespace.
+ (Before FreeBSD 11.0, it was necessary to enable shared access to
+ the host's IPC namespace from jails, and take measures to avoid
+ collisions.)
</para>
- <para>
- <systemitem class="osname">FreeBSD</systemitem> versions before 4.0 work like
- old <systemitem class="osname">OpenBSD</systemitem> (see below).
- </para>
</listitem>
</varlistentry>
@@ -951,7 +915,15 @@ kern.ipc.semmns=512
</term>
<listitem>
<para>
- In <systemitem class="osname">NetBSD</systemitem> 5.0 and later,
+ The default shared memory settings are usually good enough, unless
+ you have set <literal>shared_memory_type</literal> to <literal>sysv</literal>.
+ You will usually want to increase <literal>kern.ipc.semmni</literal>
+ and <literal>kern.ipc.semmns</literal>,
+ as <systemitem class="osname">NetBSD</systemitem>'s default settings
+ for these are uncomfortably small.
+ </para>
+
+ <para>
IPC parameters can be adjusted using <command>sysctl</command>,
for example:
<screen>
@@ -962,25 +934,12 @@ kern.ipc.semmns=512
</para>
<para>
- You will usually want to increase <literal>kern.ipc.semmni</literal>
- and <literal>kern.ipc.semmns</literal>,
- as <systemitem class="osname">NetBSD</systemitem>'s default settings
- for these are uncomfortably small.
- </para>
-
- <para>
- 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 <command>sysctl</command>
+ If you have set <literal>shared_memory_type</literal> to
+ <literal>sysv</literal>, 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 <command>sysctl</command>
setting <literal>kern.ipc.shm_use_phys</literal>.
</para>
-
- <para>
- <systemitem class="osname">NetBSD</systemitem> versions before 5.0
- work like old <systemitem class="osname">OpenBSD</systemitem>
- (see below), except that kernel parameters should be set with the
- keyword <literal>options</literal> not <literal>option</literal>.
- </para>
</listitem>
</varlistentry>
@@ -990,17 +949,8 @@ kern.ipc.semmns=512
</term>
<listitem>
<para>
- In <systemitem class="osname">OpenBSD</systemitem> 3.3 and later,
- IPC parameters can be adjusted using <command>sysctl</command>,
- for example:
-<screen>
-<prompt>#</prompt> <userinput>sysctl kern.seminfo.semmni=100</userinput>
-</screen>
- To make these settings persist over reboots, modify
- <filename>/etc/sysctl.conf</filename>.
- </para>
-
- <para>
+ The default shared memory settings are usually good enough, unless
+ you have set <literal>shared_memory_type</literal> to <literal>sysv</literal>.
You will usually want to
increase <literal>kern.seminfo.semmni</literal>
and <literal>kern.seminfo.semmns</literal>,
@@ -1009,22 +959,13 @@ kern.ipc.semmns=512
</para>
<para>
- In older <systemitem class="osname">OpenBSD</systemitem> versions,
- you will need to build a custom kernel to change the IPC parameters.
- Make sure that the options <varname>SYSVSHM</varname>
- and <varname>SYSVSEM</varname> are enabled, too. (They are by
- default.) The following shows an example of how to set the various
- parameters in the kernel configuration file:
-<programlisting>
-option SYSVSHM
-option SHMMAXPGS=4096
-option SHMSEG=256
-
-option SYSVSEM
-option SEMMNI=256
-option SEMMNS=512
-option SEMMNU=256
-</programlisting>
+ IPC parameters can be adjusted using <command>sysctl</command>,
+ for example:
+<screen>
+<prompt>#</prompt> <userinput>sysctl kern.seminfo.semmni=100</userinput>
+</screen>
+ To make these settings persist over reboots, modify
+ <filename>/etc/sysctl.conf</filename>.
</para>
</listitem>
@@ -1037,9 +978,6 @@ option SEMMNU=256
<listitem>
<para>
The default settings tend to suffice for normal installations.
- On <productname>HP-UX</productname> 10, the factory default for
- <varname>SEMMNS</varname> is 128, which might be too low for larger
- database sites.
</para>
<para>
<acronym>IPC</acronym> parameters can be set in the <application>System
@@ -1058,11 +996,10 @@ option SEMMNU=256
</term>
<listitem>
<para>
- The default maximum segment size is 32 MB, and the
- default maximum total size is 2097152
- pages. A page is almost always 4096 bytes except in unusual
- kernel configurations with <quote>huge pages</quote>
- (use <literal>getconf PAGE_SIZE</literal> to verify).
+ The default shared memory settings are usually good enough, unless
+ you have set <literal>shared_memory_type</literal> to <literal>sysv</literal>,
+ and even then only on older kernel versions that shipped with low defaults.
+ System V semaphores are not used on this platform.
</para>
<para>
@@ -1072,25 +1009,10 @@ option SEMMNU=256
<prompt>$</prompt> <userinput>sysctl -w kernel.shmmax=17179869184</userinput>
<prompt>$</prompt> <userinput>sysctl -w kernel.shmall=4194304</userinput>
</screen>
- In addition these settings can be preserved between reboots in
- the file <filename>/etc/sysctl.conf</filename>. Doing that is
- highly recommended.
+ These settings can be preserved between reboots in
+ the file <filename>/etc/sysctl.conf</filename>.
</para>
- <para>
- Ancient distributions might not have the <command>sysctl</command> program,
- but equivalent changes can be made by manipulating the
- <filename>/proc</filename> file system:
-<screen>
-<prompt>$</prompt> <userinput>echo 17179869184 >/proc/sys/kernel/shmmax</userinput>
-<prompt>$</prompt> <userinput>echo 4194304 >/proc/sys/kernel/shmall</userinput>
-</screen>
- </para>
-
- <para>
- The remaining defaults are quite generously sized, and usually
- do not require changes.
- </para>
</listitem>
</varlistentry>
@@ -1100,6 +1022,10 @@ option SEMMNU=256
<indexterm><primary>macOS</primary><secondary>IPC configuration</secondary></indexterm>
</term>
<listitem>
+ <para>
+ The default shared memory and semaphore settings are usually good enough, unless
+ you have set <literal>shared_memory_type</literal> to <literal>sysv</literal>.
+ </para>
<para>
The recommended method for configuring shared memory in macOS
is to create a file named <filename>/etc/sysctl.conf</filename>,
@@ -1117,8 +1043,7 @@ kern.sysv.shmall=1024
</para>
<para>
- Beware that recent releases of macOS ignore attempts to set
- <varname>SHMMAX</varname> to a value that isn't an exact multiple of 4096.
+ <varname>SHMMAX</varname> can only be set to a multiple of 4096.
</para>
<para>
@@ -1126,75 +1051,22 @@ kern.sysv.shmall=1024
</para>
<para>
- In older macOS versions, you will need to reboot to have changes in the
- shared memory parameters take effect. As of 10.5 it is possible to
- change all but <varname>SHMMNI</varname> on the fly, using
+ It is possible to change all but <varname>SHMMNI</varname> on the fly, using
<application>sysctl</application>. But it's still best to set up your preferred
values via <filename>/etc/sysctl.conf</filename>, so that the values will be
kept across reboots.
</para>
- <para>
- The file <filename>/etc/sysctl.conf</filename> is only honored in macOS
- 10.3.9 and later. If you are running a previous 10.3.x release,
- you must edit the file <filename>/etc/rc</filename>
- and change the values in the following commands:
-<programlisting>
-sysctl -w kern.sysv.shmmax
-sysctl -w kern.sysv.shmmin
-sysctl -w kern.sysv.shmmni
-sysctl -w kern.sysv.shmseg
-sysctl -w kern.sysv.shmall
-</programlisting>
- Note that
- <filename>/etc/rc</filename> is usually overwritten by macOS system updates,
- so you should expect to have to redo these edits after each update.
- </para>
-
- <para>
- In macOS 10.2 and earlier, instead edit these commands in the file
- <filename>/System/Library/StartupItems/SystemTuning/SystemTuning</filename>.
- </para>
</listitem>
</varlistentry>
-
<varlistentry>
- <term><systemitem class="osname">Solaris</systemitem> 2.6 to 2.9 (Solaris
- 6 to Solaris 9)
- <indexterm><primary>Solaris</primary><secondary>IPC configuration</secondary></indexterm>
- </term>
+ <term><systemitem class="osname">Solaris</systemitem></term>
+ <term><systemitem class="osname">illumos</systemitem></term>
<listitem>
<para>
- The relevant settings can be changed in
- <filename>/etc/system</filename>, for example:
-<programlisting>
-set shmsys:shminfo_shmmax=0x2000000
-set shmsys:shminfo_shmmin=1
-set shmsys:shminfo_shmmni=256
-set shmsys:shminfo_shmseg=256
-
-set semsys:seminfo_semmap=256
-set semsys:seminfo_semmni=512
-set semsys:seminfo_semmns=512
-set semsys:seminfo_semmsl=32
-</programlisting>
- You need to reboot for the changes to take effect. See also
- <ulink url="http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html"></ulink>
- for information on shared memory under older versions of Solaris.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><systemitem class="osname">Solaris</systemitem> 2.10 (Solaris
- 10) and later</term>
- <term><systemitem class="osname">OpenSolaris</systemitem></term>
- <listitem>
- <para>
- In Solaris 10 and later, and OpenSolaris, the default shared memory and
- semaphore settings are good enough for most
- <productname>PostgreSQL</productname> applications. Solaris now defaults
+ The default shared memory and semaphore settings are usually good enough for most
+ <productname>PostgreSQL</productname> applications. Solaris defaults
to a <varname>SHMMAX</varname> of one-quarter of system <acronym>RAM</acronym>.
To further adjust this setting, use a project setting associated
with the <literal>postgres</literal> user. For example, run the
@@ -1415,7 +1287,7 @@ default:\
</indexterm>
<para>
- In Linux 2.4 and later, the default virtual memory behavior is not
+ The default virtual memory behavior 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
@@ -1462,7 +1334,7 @@ Out of Memory: Killed process 12345 (postgres).
</para>
<para>
- On Linux 2.6 and later, it is possible to modify the
+ It is possible to modify the
kernel's behavior so that it will not <quote>overcommit</quote> memory.
Although this setting will not prevent the <ulink
url="https://lwn.net/Articles/104179/">OOM killer</ulink> from being invoked
@@ -1507,29 +1379,6 @@ export PG_OOM_ADJUST_VALUE=0
whole point is to ensure that the postmaster has a preferential setting.
</para>
- <para>
- Older Linux kernels do not offer <filename>/proc/self/oom_score_adj</filename>,
- but may have a previous version of the same functionality called
- <filename>/proc/self/oom_adj</filename>. This works the same except the disable
- value is <literal>-17</literal> not <literal>-1000</literal>.
- </para>
-
- <note>
- <para>
- Some vendors' Linux 2.4 kernels are reported to have early versions
- of the 2.6 overcommit <command>sysctl</command> parameter. However, setting
- <literal>vm.overcommit_memory</literal> to 2
- on a 2.4 kernel that does not have the relevant code will make
- things worse, not better. It is recommended that you inspect
- the actual kernel source code (see the function
- <function>vm_enough_memory</function> in the file <filename>mm/mmap.c</filename>)
- to verify what is supported in your kernel before you try this in a 2.4
- installation. The presence of the <filename>overcommit-accounting</filename>
- documentation file should <emphasis>not</emphasis> be taken as evidence that the
- feature is there. If in any doubt, consult a kernel expert or your
- kernel vendor.
- </para>
- </note>
</sect2>
<sect2 id="linux-huge-pages">
--
2.20.1
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
Attachments:
doc-minor-fixes.patchtext/x-diff; charset=us-ascii; name=doc-minor-fixes.patchDownload
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:
/messages/by-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
/messages/by-id/5915.1481218827@sss.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.
/messages/by-id/5915.1481218827@sss.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.
Attachments:
0001-Doc-Update-example-symptom-of-systemd-misconfigurati.patchtext/x-patch; charset=US-ASCII; name=0001-Doc-Update-example-symptom-of-systemd-misconfigurati.patchDownload
From 5005e5b143bdce05e4d8c9a5598a2114bfe7da2f Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
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)
<para>
If <productname>systemd</productname> 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)
</para>
<para>
- 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
<screen>
-LOG: semctl(1234567890, 0, IPC_RMID, ...) failed: Invalid argument
+WARNING: could not remove shared memory segment "/PostgreSQL.1450751626": No such file or directory
</screen>
Different types of IPC objects (shared memory vs. semaphores, System V
vs. POSIX) are treated slightly differently
--
2.20.1
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