public inbox for [email protected]
help / color / mirror / Atom feedRelease postmaster working memory context in slotsync worker
2+ messages / 2 participants
[nested] [flat]
* Release postmaster working memory context in slotsync worker
@ 2026-02-27 16:25 Fujii Masao <[email protected]>
2026-02-27 17:32 ` Re: Release postmaster working memory context in slotsync worker Andres Freund <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Fujii Masao @ 2026-02-27 16:25 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
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
Attachments:
[application/octet-stream] v1-0001-Release-postmaster-working-memory-context-in-slot.patch (1.2K, 2-v1-0001-Release-postmaster-working-memory-context-in-slot.patch)
download | inline diff:
From c40c231a45078c8f749b200fb036b4700509efbd Mon Sep 17 00:00:00 2001
From: Fujii Masao <[email protected]>
Date: Sat, 28 Feb 2026 00:50:11 +0900
Subject: [PATCH v1] Release postmaster working memory context in slotsync
worker.
Child processes do not need the postmaster's working memory context and
normally release it at the start of their main entry point. However,
the slotsync worker forgot to do so.
This commit makes the slotsync worker release the postmaster's working memory
context at startup, avoiding unnecessary memory usage in that process.
---
src/backend/replication/logical/slotsync.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/logical/slotsync.c b/src/backend/replication/logical/slotsync.c
index 062a08ccb88..4c05d1a98db 100644
--- a/src/backend/replication/logical/slotsync.c
+++ b/src/backend/replication/logical/slotsync.c
@@ -1480,6 +1480,13 @@ ReplSlotSyncWorkerMain(const void *startup_data, size_t startup_data_len)
Assert(startup_data_len == 0);
+ /* Release postmaster's working memory context */
+ if (PostmasterContext)
+ {
+ MemoryContextDelete(PostmasterContext);
+ PostmasterContext = NULL;
+ }
+
init_ps_display(NULL);
Assert(GetProcessingMode() == InitProcessing);
--
2.51.2
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Release postmaster working memory context in slotsync worker
2026-02-27 16:25 Release postmaster working memory context in slotsync worker Fujii Masao <[email protected]>
@ 2026-02-27 17:32 ` Andres Freund <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Andres Freund @ 2026-02-27 17:32 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-02-27 17:32 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-02-27 16:25 Release postmaster working memory context in slotsync worker Fujii Masao <[email protected]>
2026-02-27 17:32 ` Andres Freund <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox