Re: doc: Document Linux cgroup memory limits

Hi Takeshi,

> I noticed some of the topics are already written in the above
> 'overcommit' section. For example, how to tune memory related parameters
> and how postgres behaves after OOM killer terminates postgresql.

Both are right. To give João something concrete to decide on, I applied
v5 on current master (it applies with a 6-line offset, on top of your
febd05600d7) and went through it against the overcommit section topic by
topic.

Already covered by the overcommit section:

- A server process other than the postmaster is killed: crash restart,
or shutdown with restart_after_crash off (v5 2nd paragraph).
- The postmaster is killed: no automatic restart (v5 3rd paragraph).
- Sizing shared_buffers, work_mem, hash_mem_multiplier and
max_connections (v5 4th paragraph). The overcommit section has those
four; v5 adds maintenance_work_mem, the overcommit section adds
connection pooling.

The first two only became duplicates with your fix on Oct 16. v5 is
from Oct 1, when the overcommit section still said existing connections
"will continue to function normally", so at the time v5 contradicted
it. Now the two agree.

Not in the overcommit section, and specific to cgroups:

- the limit applies regardless of vm.overcommit_memory
- memory.max (v2 only)
- the OOM killer runs inside the cgroup, so allocations usually don't
fail with an error
- memory.oom.group kills the whole cgroup except processes with
oom_score_adj -1000, and recent Kubernetes sets it by default
- shared memory and each process's private memory both count
- huge pages count only with memory_hugetlb_accounting

Not in the overcommit section, but not specific to cgroups either:
systemd's OOMPolicy, the postmaster not logging its own termination, and
the safety margin below the limit. The -1000 protection for the
postmaster is already a reference to the overcommit section rather than
a copy.

So 3 of the 14 topics overlap, in three sentences (at most 13 of the 44
lines of text). The cgroup-specific part is about 25 lines, which is a
lot for a Note. That fits your option 1: keep the section and replace
those three sentences with a reference to the overcommit section.
Option 2 also works, but then the three general topics above would fit
better in the overcommit text itself than in a cgroup Note. Either way,
the choice is João's -- I'm just putting the numbers next to your two
options.

On my side: when I said v5 stays Ready for Committer, I was reviewing
the changed paragraph and checking that the docs build. I didn't look
at how the section fits with the overcommit one, and your point about
that is fair. The content still reads right to me.

Regards,
Manu