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
