=?UTF-8?B?QWxlxaEgWmVsZW7DvQ==?= <zeleny.ales@gmail.com> 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
