Re: Release postmaster working memory context in slotsync worker

---- 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.
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.
Regards,
Tiancheng Ge