> On Mar 18, 2026, at 21:41, getiancheng <[email protected]> wrote:
>
>
>
> ---- Replied Message ----
> From Fujii Masao<[email protected]>
> Date 3/18/2026 14:31
> To Tom Lane<[email protected]>
> Cc Andres Freund<[email protected]>,
> PostgreSQL Hackers<[email protected]>
> Subject Re: Release postmaster working memory context in slotsync worker
> On Sat, Feb 28, 2026 at 2:58 AM Tom Lane <[email protected]> wrote:
>
> Andres Freund <[email protected]> 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/
