From: Jack Ng <Jack.Ng@huawei.com>
To: Dmitry Dolgov <9erthalion6@gmail.com>
CC: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Robert Haas
	<robertmhaas@gmail.com>, Ni Ku <jakkuniku@gmail.com>
Subject: RE: Changing shared_buffers without restart
Thread-Topic: Changing shared_buffers without restart
Thread-Index: AQHbl7DrFzUaSyTydEunWI983IaxOrNc1X6AgGMtZVaABTbmwA==
Date: Tue, 6 May 2025 04:23:07 +0000
Message-ID: <fbdc6674ae54420d96368079bf76dd74@huawei.com>
References: <xuuxvlhom2tiinwwnh7r6wds74o2fkwryy6palehytuzm76l4t@3q7lszfqic3b>
 <CAExHW5uJujFkJzk_YgvFDKWknBBGoBpjvWB1n+k3szSN-xwN5Q@mail.gmail.com>
 <CAExHW5soDB=08jeyqn-W-=+Y86v-a5f_NJRjAdV9_yFrKpJcCw@mail.gmail.com>
 <eqs6v4rsboazl67xz3wxc6xjkgrpfybitpl45y3lmb2br67wbj@o7czebb3rlgd>
 <CAExHW5sTB1Ow0a1JtVy4PGCPckM7P1CSngJ4+LX3w+yz7rwQfQ@mail.gmail.com>
 <ywyt5gecsfjzxlvxbvingd2dps2dedpwq5l4xhfmbcci6xta2e@h7ygoxvep725>
 <CAExHW5s1b-_9GFGGOxSVimrt8oe2Y0a7vRhENrd2BSo+0Tkp-A@mail.gmail.com>
 <gzb2oqqabzqidlnumrbau2k2fscb5jo6nlpdjnf6pu5y4bk5mo@xoujqgtiqvgr>
 <CAExHW5uGozdiDm_BefS7jpQzaisCs4_nLTMF0+S_Pds49pRG_w@mail.gmail.com>
 <CAPuPUJwDa_WEVmkknyYHYub5qvBuwKyLLOOiUpyiq6Wd=9FQ_g@mail.gmail.com>
 <a2b6laawu4iya4zu737lhgdbvi5bcspxkxqinzogw6o7e2yhke@ay4qtrdlyzhq>
In-Reply-To: <a2b6laawu4iya4zu737lhgdbvi5bcspxkxqinzogw6o7e2yhke@ay4qtrdlyzhq>
Accept-Language: en-CA, zh-CN, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/fbdc6674ae54420d96368079bf76dd74%40huawei.com>
Precedence: bulk

Thanks Dmitry. Right, the coordination mechanism in v4-0006 works as expect=
ed in various tests (sorry, I misunderstood some details initially).

I also want to report a couple of minor issues found during testing (which =
you may be aware of already):

1. For memory segments other the first one ('main'), the start address pass=
ed to mmap may not be aligned to 4KB or huge page size (since reserved_offs=
et may not be aligned) and cause mmap to fail.

2. Since the ratio for main/desc/iocv/checkpt/strategy in SHMEM_RESIZE_RATI=
O  are relatively small, I think we need to guard against the case where 'm=
ax_available_memory' is too small for the required sizes of these segments =
(from CalculateShmemSize).
Like when max_available_memory=3Ddefault and shared_numbers=3D128kB, 'main'=
 still needs ~109MB, but since only 10% of max_available_memory is reserved=
 for it (~102MB) and start address of the next segment is calculated based =
on reserved_offset, this would cause the mappings to overlap and memory pro=
blems later (I hit this after fixing 1.)
I suppose we can change the minimum value of max_available_memory to be lar=
ge enough, and may also adjust the ratios in SHMEM_RESIZE_RATIO to ensure t=
he reserved space of those segments are sufficient.

Regards,

Jack Ng

-----Original Message-----
From: Dmitry Dolgov <9erthalion6@gmail.com>=20
Sent: Monday, April 21, 2025 5:33 AM
To: Ni Ku <jakkuniku@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>; pgsql-hackers@postgresql=
.org; Robert Haas <robertmhaas@gmail.com>
Subject: Re: Changing shared_buffers without restart

> On Thu, Apr 17, 2025 at 07:05:36PM GMT, Ni Ku wrote:
> I also have a related question about how ftruncate() is used in the patch=
.
> In my testing I also see that when using ftruncate to shrink a shared=20
> segment, the memory is freed immediately after the call, even if other=20
> processes still have that memory mapped, and they will hit SIGBUS if=20
> they try to access that memory again as the manpage says.
>
> So am I correct to think that, to support the bufferpool shrinking=20
> case, it would not be safe to call ftruncate in AnonymousShmemResize=20
> as-is, since at that point other processes may still be using pages=20
> that belong to the truncated memory?
> It appears that for shrinking we should only call ftruncate when we're=20
> sure no process will access those pages again (eg, all processes have=20
> handled the resize interrupt signal barrier). I suppose this can be=20
> done by the resize coordinator after synchronizing with all the other pro=
cesses.
> But in that case it seems we cannot use the postmaster as the=20
> coordinator then? b/c I see some code comments saying the postmaster=20
> does not have waiting infrastructure... (maybe even if the postmaster=20
> has waiting infra we don't want to use it anyway since it can be=20
> blocked for a long time and won't be able to serve other requests).

There is already a coordination infrastructure, implemented in the patch 00=
06, which will take care of this and prevent access to the shared memory un=
til everything is resized.