Subject: Release postmaster working memory context in slotsync worker

From: Fujii Masao <[email-masked]>
Date: Sat, 28 Feb 2026 01:25:12 +0900

Hi,

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.

Currently, pg_log_backend_memory_contexts() reports the following
postmaster-related memory contexts in the slotsync worker:

    LOG:  level: 2; Postmaster: 21984 total in 2 blocks; 5600 free (7
chunks); 16384 used
    LOG:  level: 3; ident parser context: 1024 total in 1 blocks; 784
free (0 chunks); 240 used
    LOG:  level: 3; hba parser context: 25600 total in 6 blocks; 9864
free (11 chunks); 15736 used

With the attached patch, these contexts are no longer present.

Regards,

-- 
Fujii Masao

---

From: Andres Freund <[email-masked]>
Date: Fri, 27 Feb 2026 12:32:24 -0500

Hi,

> worker release the postmaster's working memory context at startup.

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