Re: Release postmaster working memory context in slotsync worker

> On Mar 18, 2026, at 21:41, getiancheng <getiancheng_2012(at)163(dot)com> wrote:
>
>
>
> ---- Replied Message ----
> From Fujii Masao<masao(dot)fujii(at)gmail(dot)com>
> Date 3/18/2026 14:31
> To Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Cc Andres Freund<andres(at)anarazel(dot)de>,
> PostgreSQL Hackers<pgsql-hackers(at)lists(dot)postgresql(dot)org>
> Subject Re: Release postmaster working memory context in slotsync worker
> On Sat, Feb 28, 2026 at 2:58 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Andres Freund <andres(at)anarazel(dot)de> writes:
> 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.
>
> 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.
>
> Meh. I think that's optimizing for the wrong thing. To my mind the
> point of releasing that context is to be sure that child processes
> don't have access to postmaster-private data.
>
> Okay, I've included this point in the commit message of the patch.
>
>
> Admittedly, we're not
> doing anything as drastic as zeroing out the memory, but it'll soon
> be overwritten as the child starts up and populates its caches.
>
> Yes.
>
> Attached is a rebased version of the patch. I'm thinking to commit it.
>
> Regards,
>
> --
> Fujii Masao
>
> Hi
>
> The change LGTM, since other worker processes do the same thing.

Also LGTM.

> I am a bit confused with the comment message "ensuring it does not have access to postmaster-private data".
> As a child of postmaster, the worker inherits PostmasterContext at fork() time, so the data is already copied into the child's address space. MemoryContextDelete() does not wipe that memory, so I don't think this literally "ensures it does not have access" to the data.
> My understanding is that the main purpose here is to make sure the child does not continue to use PostmasterContext by mistake, rather than to prevent access in a strict sense. Maybe the commit message could say that a bit more precisely.

I had the same feeling when I first read that commit message. But after reading Andres' email, I think I understand why that wording was added.

Still, the current phrasing seems a bit too strong to me. Strictly speaking, the memory is already inherited at fork time, so this is not making access impossible in an absolute sense. What this patch really does is remove the inherited PostmasterContext, so the child no longer retains that postmaster-private data through that context.

Maybe we could phrase in some way like: "so that it no longer retains access to postmaster-private data through PostmasterContext”.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/