Re: Changing shared_buffers without restart

> On Mon, Sep 29, 2025 at 12:21:08PM +0530, Ashutosh Bapat wrote:
> On Sun, Sep 28, 2025 at 2:54 PM Dmitry Dolgov <9erthalion6(at)gmail(dot)com> wrote:
> >
> > > On Thu, Sep 18, 2025 at 10:25:29AM +0530, Ashutosh Bapat wrote:
> > > Given these things, I think we should set up the buffer lookup table
> > > to hold maximum entries required to expand the buffer pool to its
> > > maximum, right at the beginning.
> >
> > Thanks for investigating. I think another option would be to rebuild the
> > buffer lookup table (create a new table based on the new size and copy
> > the data over from the original one) as part of the resize procedure,
> > alongsize with buffers eviction and initialization. From what I recall
> > the size of buffer lookup table is about two orders of magnitude lower
> > than shared buffers, so the overhead should not be that large even for
> > significant amount of buffers.
>
> The proposal will work but will require significant work:
>
> 1. The pointer to the shared buffer lookup table will change.

Which pointers you mean? AFAICT no operation on the buffer lookup table
returns a pointer (they work with buffer id or a hash) and keys are
compared by value as well.

> we can not have few processes accessing old lookup table and few
> processes new one. That has potential to make many processes wait for
> a very long time.

As I've mentioned above, size of the buffer lookup table is few
magnitudes lower than shared buffers, so I doubt about "a very long
time". But it can be measured.

> 2. The memory consumed by the old buffer lookup table will need to be
> "freed" to the OS. The only way to do so is by having a new memory
> segment

Shared buffer lookup table already lives in it's own segment as
implemented in the current patch, so I don't see any problem here.

I see you folks are inclined to keep some small segments static and
allocate maximum allowed memory for it. It's an option, at the end of
the day we need to experiment and measure both approaches.