Re: Changing shared_buffers without restart

Hi Palak,

> Yes. v20260908-0016 rechecks BM_TAG_VALID under LockBufHdr() and does
> UnlockBufHdr() + continue instead of asserting when the tag was
> cleared concurrently.
>
> Right, that line predates the MADV_REMOVE range fix. Removed it in
> v20260908-0015.

Thanks. 0015 and 0016 LGTM.

I also tested the patches and did some more review.

With shared_buffers=32MB and max_shared_buffers left at its default, parallel
workers fail to start, even without any resize:
FATAL: failed to initialize shared_buffers to 16384
CONTEXT: parallel worker

RestoreGUCState() resets the GUC to its 128MB boot value, which exceeds
MaxNBuffers and fails the check hook.

There is also a performance issue in the grow path:
PGSharedMemoryEnsureAllocated() gets the whole structure's range, rather than
just the added range. Even a small increase makes MADV_POPULATE_WRITE walk the
existing range again, adding overhead for large buffer pools. Could we limit
this to the page-aligned [current_end, new_end), as in the shrink path?

Two minor points:
* check_shared_buffers() allows equality with MaxNBuffers, so "must be less than"
should be "must not exceed".
* In proc.c, "specifid there" should be "specified there".

Some issues raised in earlier reviews remain unaddressed. Could you include a
status list with the next update, separating resolved and unresolved items?
That would help reviewers who are new to the thread or haven't followed it for
a while.

Best regards,
Yuhang Qiu