Re: doc: Document Linux cgroup memory limits

Hi João,

Thanks for v3. The new sentence is right, and the docs build. Going
through the whole section once more, two cases behave differently
from what it says; I should have raised them with v2.

> If that is a server process other than the postmaster, the
> postmaster treats it as a crash and, unless restart_after_crash is
> turned off, restarts all server processes, disconnecting all sessions.

Not when the server runs as a systemd service, which is a common way
to set a memory limit outside containers. systemd's OOMPolicy applies
too, and its default, stop, stops the whole service after an OOM kill.
With MemoryMax=400M and no OOMPolicy set, two of three runs ended with
"received smart shutdown request" and the unit in the oom-kill failed
state, and the third was already deactivating; with
OOMPolicy=continue, the postmaster restarted all three times. Perhaps
add:

If the server runs as a systemd service, systemd's OOMPolicy setting
also applies; its default, stop, stops the whole service instead.

> If memory.oom.group is set for the cgroup, [...] the OOM killer
> instead terminates all processes of the cgroup, including the
> postmaster.

The kernel exempts processes whose oom_score_adj is -1000 from the
group kill, and that is what linux-memory-overcommit recommends for
the postmaster. With the postmaster at -1000 and memory.oom.group set
to 1, the group kill happened but the postmaster survived and
restarted the other processes, in three runs out of three. Inside a
container the postmaster usually cannot lower its own score, so the
Kubernetes case stays as you describe. Perhaps:

... the OOM killer instead terminates all processes of the cgroup
except those with an oom_score_adj of -1000, so the postmaster too,
unless it is protected as described in
<xref linkend="linux-memory-overcommit"/>.

Regards,
Manu