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 Em seg., 5 de out. de 2026 às 03:37, Jakub Wartak < [email protected]> escreveu: > On Mon, Oct 5, 2026 at 4:17 AM Joao Detomini > <[email protected]> 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 >
v5-0001-doc-Document-Linux-cgroup-memory-limits.patch
Description: Binary data
