=?UTF-8?B?QWxlxaEgWmVsZW7DvQ==?= <zeleny.ales@xxxxxxxxx> writes: > postgres=# show shared_buffers ; > shared_buffers > ---------------- > 10GB > (1 row) Oh! In that case, there is absolutely nothing to see here. This chunk: > 00007fd9b0551000 10827040K rw-s- zero (deleted) must be your shared-memory region, and it's accounting for just about all of the process's memory space. There is no reason to suspect a leak. I think you've been fooled by the fact that "top" and some other tools frequently don't report a shared-memory page as part of a process's usage until that process touches that particular page. Thus, the reported memory usage of a Postgres backend will grow over time as it randomly happens to touch different buffers within the shared buffer arena. That does not constitute a leak, but it does make such tools next door to useless for detecting actual leaks :-(. You can only believe there's a leak if the reported usage doesn't level off after reaching the vicinity of your shared memory size. So back to why you're getting these out-of-memory failures: we still don't have much info about that. I wonder whether there is something watching the total usage reported by "top" and taking action based on that entirely-misleading number. The kernel itself should be aware that there's no extra memory pressure from N backends all using the same shared memory segment, but it can be hard for outside tools to know that. At this point I suspect that PG 14.3 vs 14.4 is a red herring, and what you should be looking into is what else you updated at about the same time, particularly in the line of container management tools or the like (if you use any). regards, tom lane
