On 5/20/22 19:08, Tomas Vondra wrote:
Well, we already have the memory-accounting built into the memory
context infrastructure. It kinda does the same thing as the malloc()
wrapper, except that it does not publish the information anywhere and
it's per-context (so we have to walk the context recursively).
So maybe we could make this on-request somehow? Say, we'd a signal to
the process, and it'd run MemoryContextMemAllocated() on the top memory
context and store the result somewhere.
One remaining problem with all this is that we don't get any feedback
from calling free() telling if any memory has been returned to the OS or
not.
How portable would using sbrk() with a zero size be? If that is an
option then I could envision counting actual calls to malloc() and
whenever a GUC configurable amount is reached, use sbrk() to find out,
do the accounting in shared memory and react accordingly.
This way we are not creating another highly contended lock and use
authoritative information.
Regards, Jan
