Hi,
On 2026-02-28 01:25:12 +0900, Fujii Masao wrote:
> Child processes do not need the postmaster's working memory context and
> release it at the start of their main function. However, the slotsync worker
> appears to have missed this step.
>
> To avoid this unnecessary memory usage, I'd like to propose that the slotsync
> worker release the postmaster's working memory context at startup.
> A patch is attached.
Obviously this inconsistency is not good. However:
I think we should consider *not* releasing postmaster memory. Freeing the
memory actually can lead to an *increase* in memory usage and a slight
*decrease* in connection startup performance. The reason for that is that with
fork, memory allocated in postmaster is handled by copy-on-write in the
children.
If the memory allocated by postmaster is freed in the children, the process of
freeing requires some modifications to copy-on-write memory (leading to an
increase in memory usage and page faults) and it allows the system allocator
to reuse the malloc'd regions, which then leads to more copy on write.
It's however annoying that the memory shows up in pg_backend_memory_contexts,
so maybe what postmaster children should do is to instead is to move its
parent to be NULL? That will still incur COW copying (due to modifying
PostmasterContext's ->{parent,prevchild,nextchild} pointers), but only a
single page, instead of multiple pages.
Or perhaps PostmasterContext should just not be below TopMemoryContext, then
we wouldn't need to do anything.
The tradeoff might be different if postmaster modified its allocated memory
more, since that also leads to CoW, but from what I can tell, that doesn't
happen very much.
See [1] for some numbers.
Perhaps this is not worth worrying about - currently with openssl linked in,
the bulk of the overhead is from that. But as the numbers in [1] show, the
MemoryContextDelete(PostmasterContext) does make a difference.
Greetings,
Andres Freund
[1]
https://postgr.es/m/hgs2vs74tzxigf2xqosez7rpf3ia5e7izalg5gz3lv3nqfptxx%40thanmprbpl4el
