Re: Release postmaster working memory context in slotsync worker
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-03-18T06:31:23Z
Lists: pgsql-hackers
Attachments
- v2-0001-Release-postmaster-working-memory-context-in-slot.patch (application/octet-stream) patch v2-0001
On Sat, Feb 28, 2026 at 2:58 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Andres Freund <andres@anarazel.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
Commits
-
Release postmaster working memory context in slotsync worker
- 93dc1ace2007 19 (unreleased) landed