Hi Jakub,
Thanks for looking at it. You're right that the last paragraph read
as if choosing those settings is enough to stay under the limit, and
that isn't true: the total can be many times work_mem. Attached v5
softens that sentence and recommends leaving a safety margin below
the limit, the same way the work_mem docs put it.
Overcommit inside cgroups and RLIMIT_DATA seem like a separate
discussion from this docs patch, so I left them out.
Changes since v4: only the last paragraph of the section.
Thanks,
João Marcelo
On Mon, Oct 5, 2026 at 4:17 AM Joao Detomini
<joao.detomini@enterprisedb.com> wrote:
>
> Hi Manu,
>
> Thanks for the quick response. Attached v4 with both points: the systemd
> OOMPolicy note, and the oom_score_adj -1000 exemption for the group
> kill, with a pointer to the overcommit section. I also resolved the ambiguity
> that arose after this new insertion.
+1 to the documenting this, but it's more than just set couple of GUCs
to avoid OOM:
We are kind of weak on self-limiting memory usage (there's new leak every
now and then, and people are complaining about work_mem not working). IMHO
running without vm.overcommit_memory=2 and without rotating connections
every couple hours/days [to release leaks/fat from free() caching by e.g.
glibc [1][2]] is basically prolonged outage sooner or later before one hits
suchleaks, dunno what people do with cgroups2 do to avoid this. So to me it's
some kind of risky to run PostgreSQL on cgroups2 in the first place. IMHO
kernel should be enhanced to implement overcommit_memory=2 within cgroups,
but I understand that stuff that some stuff is implemented during page-fault
handling (and not memory allocation - the brk() itself), so it is impossible?
The patch mentions some GUC, but do in my experience, that's not the whole
truth, there's plenty of other things: number of relations involved, libc/
malloc implementation, and so on.
Two years ago I was thinking we could simply - in theory - issue
setrlimit(RLIMIT_DATA) (per process to limit each backend to strict X MB),
but AFAIR(?) Andres told me it is not really usable there as it may cause
SIGSEGVs in case of hitting the limit when growing stack and not just
overallocating memory (if I recall correctly). Or maybe I misunderstood and
I couldn't reproducce this on modern kernels.
-J.
[1] - https://www.postgresql.org/message-id/CA%2BT%3D_GV-igvf8gLRK4w22aN1qB6F1zgHD9dxnEHtK%3DXEoTTPEA%40mail.gmail.com
[2] - https://www.postgresql.org/message-id/flat/3424675.QJadu78ljV%40aivenlaptop
