MIME-Version: 1.0
References: 
 <CAHGQGwHO05JaUpgKF8FBDmPdBUJsK22axRRcgmAUc2Jyi8OK8g@mail.gmail.com>
 <ukpuo66v3k5z5cpwfbofa3zwdgdb53thbxemgqvtsnf7gdf5ew@ixgj5hs4bwu6>
 <986903.1772215127@sss.pgh.pa.us>
In-Reply-To: <986903.1772215127@sss.pgh.pa.us>
From: Fujii Masao <masao.fujii@gmail.com>
Date: Wed, 18 Mar 2026 15:31:23 +0900
Message-ID: 
 <CAHGQGwFu0tam9i2UxRHY+mrB-0YZVfWZPheKYy5V2KfB-WxuGQ@mail.gmail.com>
Subject: Re: Release postmaster working memory context in slotsync worker
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/mixed; boundary="000000000000844815064d469a9b"
Archived-At: 
 <https://www.postgresql.org/message-id/CAHGQGwFu0tam9i2UxRHY%2BmrB-0YZVfWZPheKYy5V2KfB-WxuGQ%40mail.gmail.com>
Precedence: bulk

--000000000000844815064d469a9b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 28, 2026 at 2:58=E2=80=AFAM 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 an=
d
> >> 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 t=
he
> > memory actually can lead to an *increase* in memory usage and a slight
> > *decrease* in connection startup performance. The reason for that is th=
at 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,

--=20
Fujii Masao

--000000000000844815064d469a9b
Content-Type: application/octet-stream;
	name="v2-0001-Release-postmaster-working-memory-context-in-slot.patch"
Content-Disposition: attachment;
	filename="v2-0001-Release-postmaster-working-memory-context-in-slot.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mmvnxs7c0>
X-Attachment-Id: f_mmvnxs7c0

RnJvbSBjYTE1YzM4MDJiZTJhYmFjNThkMjg4YTRkMWM5MTk0M2E4NjdhNDZkIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBGdWppaSBNYXNhbyA8ZnVqaWlAcG9zdGdyZXNxbC5vcmc+CkRh
dGU6IFdlZCwgMTggTWFyIDIwMjYgMTU6MjY6MDAgKzA5MDAKU3ViamVjdDogW1BBVENIIHYyXSBS
ZWxlYXNlIHBvc3RtYXN0ZXIgd29ya2luZyBtZW1vcnkgY29udGV4dCBpbiBzbG90c3luYwogd29y
a2VyCgpDaGlsZCBwcm9jZXNzZXMgZG8gbm90IG5lZWQgdGhlIHBvc3RtYXN0ZXIncyB3b3JraW5n
IG1lbW9yeSBjb250ZXh0IGFuZApub3JtYWxseSByZWxlYXNlIGl0IGF0IHRoZSBzdGFydCBvZiB0
aGVpciBtYWluIGVudHJ5IHBvaW50LiBIb3dldmVyLAp0aGUgc2xvdHN5bmMgd29ya2VyIGZvcmdv
dCB0byBkbyBzby4KClRoaXMgY29tbWl0IG1ha2VzIHRoZSBzbG90c3luYyB3b3JrZXIgcmVsZWFz
ZSB0aGUgcG9zdG1hc3RlcidzIHdvcmtpbmcKbWVtb3J5IGNvbnRleHQgYXQgc3RhcnR1cCwgZW5z
dXJpbmcgaXQgZG9lcyBub3QgaGF2ZSBhY2Nlc3MgdG8KcG9zdG1hc3Rlci1wcml2YXRlIGRhdGEu
Ci0tLQogc3JjL2JhY2tlbmQvcmVwbGljYXRpb24vbG9naWNhbC9zbG90c3luYy5jIHwgNyArKysr
KysrCiAxIGZpbGUgY2hhbmdlZCwgNyBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEvc3JjL2Jh
Y2tlbmQvcmVwbGljYXRpb24vbG9naWNhbC9zbG90c3luYy5jIGIvc3JjL2JhY2tlbmQvcmVwbGlj
YXRpb24vbG9naWNhbC9zbG90c3luYy5jCmluZGV4IGU3NWRiNjllM2Y2Li5kMTAzMjIzYzIxZiAx
MDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvcmVwbGljYXRpb24vbG9naWNhbC9zbG90c3luYy5jCisr
KyBiL3NyYy9iYWNrZW5kL3JlcGxpY2F0aW9uL2xvZ2ljYWwvc2xvdHN5bmMuYwpAQCAtMTQ4NSw2
ICsxNDg1LDEzIEBAIFJlcGxTbG90U3luY1dvcmtlck1haW4oY29uc3Qgdm9pZCAqc3RhcnR1cF9k
YXRhLCBzaXplX3Qgc3RhcnR1cF9kYXRhX2xlbikKIAogCUFzc2VydChzdGFydHVwX2RhdGFfbGVu
ID09IDApOwogCisJLyogUmVsZWFzZSBwb3N0bWFzdGVyJ3Mgd29ya2luZyBtZW1vcnkgY29udGV4
dCAqLworCWlmIChQb3N0bWFzdGVyQ29udGV4dCkKKwl7CisJCU1lbW9yeUNvbnRleHREZWxldGUo
UG9zdG1hc3RlckNvbnRleHQpOworCQlQb3N0bWFzdGVyQ29udGV4dCA9IE5VTEw7CisJfQorCiAJ
aW5pdF9wc19kaXNwbGF5KE5VTEwpOwogCiAJQXNzZXJ0KEdldFByb2Nlc3NpbmdNb2RlKCkgPT0g
SW5pdFByb2Nlc3NpbmcpOwotLSAKMi41MS4yCgo=
--000000000000844815064d469a9b--