nothing about it. I recently posted a
docs patch about how the cgroup
OOM killer behaves , and while testing that I tried the obvious
case: postgres:17 (17.11) with -m 512m and no swap, and six sessions
each sorting 3M rows with work_mem = 300MB. One backend got SIGKILL,
the postmaster restarted everything, and all six sessions lost their
connection. Nobody got an out-of-memory error, since the allocations
themselves succeeded. The server had started with the usual
shared_buffers = 128MB and max_connections = 100, so nothing in it
reflected the 512MB limit.
I couldn't find any code in the tree that looks at cgroups, nor an
earlier discussion in the archives, though I may have missed one.
What I have in mind is small: a SQL function that returns the memory
limit of the cgroup the server runs in (NULL if there is none, or not
on Linux), so tools and operators don't have to parse /sys/fs/cgroup
themselves. It would not change any defaults or behavior.
Does that seem worth having in core, or would you rather see it in
contrib or left to external tools? I'd only look at cgroup v2 at
first. If the idea sounds reasonable, I'm happy to write a patch.
Thanks,
João Marcelo
