Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vw273-00GX0E-2B for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Feb 2026 17:58:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vw272-005MxI-23 for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Feb 2026 17:58:52 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vw272-005Mws-17 for pgsql-hackers@lists.postgresql.org; Fri, 27 Feb 2026 17:58:52 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vw26z-00000001XTp-1dNi for pgsql-hackers@lists.postgresql.org; Fri, 27 Feb 2026 17:58:51 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 61RHwlnq986904; Fri, 27 Feb 2026 12:58:47 -0500 From: Tom Lane To: Andres Freund cc: Fujii Masao , PostgreSQL Hackers Subject: Re: Release postmaster working memory context in slotsync worker In-reply-to: References: Comments: In-reply-to Andres Freund message dated "Fri, 27 Feb 2026 12:32:24 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <986902.1772215127.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Feb 2026 12:58:47 -0500 Message-ID: <986903.1772215127@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund 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 w= orker >> appears to have missed this step. > Obviously this inconsistency is not good. However: > I think we should consider *not* releasing postmaster memory. Freeing th= e > memory actually can lead to an *increase* in memory usage and a slight > *decrease* in connection startup performance. The reason for that is tha= t 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. 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. regards, tom lane