Hi, When Postgres runs in a container with a memory limit, the server knows nothing about it. I recently posted a docs patch <https://commitfest.postgresql.org/patch/7381/> 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
