Disabling memory overcommit deemed dangerous

Hi hackers,

In our documentation we recommend disabling memory overcommit to prevent
the OOM killer from kicking in, see [1]. Accordingly, we expect
PostgreSQL to handle OOM situations gracefully. In my experience there
are unfortunately several severe problems with that approach:

1. PostgreSQL contains code paths that aren't safe against failing
memory allocations. Examples are broken cleanup code, see [2], or
various calls to strdup() where we don't check the return value.

2. On Linux, running OOM during stack expansion triggers SIGSEGV. This
is not a theoretical concern. I hit this case in my tests. We could set
up a custom stack via MAP_STACK | MAP_GROWSDOWN, but in practice that's
very tricky because of ASLR. The only real alternative is committing (=
writing to) all memory on backend startup. Problem with that approach is
that all that memory would count already towards the commit limit. We
might get away with that if we lower the maximum stack size significantly.

3. Other processes running on the same system are mostly not safe
against failing memory allocations. In my tests I ended up multiple
times with a server that I couldn't log in anymore because some related
process had crashed due to running OOM.

I cannot see how someone would today reliably run a PostgreSQL server
with memory overcommit disabled, if it truly runs occasionally OOM. Even
if we fixed (1) and (2) we would still be left with (3). cgroups might
help with (3) but the last time I checked they didn't properly implement
memory overcommit.

My proposal is to remove the part about disabling memory overcommit from
the documentation, or alternatively, describe the pros and cons of both
approaches. Thoughts?

[1]
https://www.postgresql.org/docs/current/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT
[2]
https://www.postgresql.org/message-id/flat/b12f9e22-2618-42b8-8644-88bae192c7fd%40gmail.com

--
David Geier