Re: Changing shared_buffers without restart - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: Changing shared_buffers without restart
Date
Msg-id y3dv2iuwh7tai5pztshiezdtffpfzt6t3nj4vbs6jmywhyy4zo@wxqvktyq5ix5
Whole thread Raw
In response to Re: Changing shared_buffers without restart  (Andres Freund <andres@anarazel.de>)
Responses Re: Changing shared_buffers without restart
List pgsql-hackers
> On Mon, Jul 14, 2025 at 10:23:23AM -0400, Andres Freund wrote:
> > Those steps are separated in time, and I'm currently trying to understand
> > what are the consequences of performing them in different order and whether
> > there are possible concurrency issues under various scenarios. Does this
> > make more sense, or still not?
>
> I still don't understand why it'd ever make sense to put a buffer onto the
> freelist before updating NBuffers first.

Depending on how NBuffers is updated, different backends may have
different value of NBuffers for a short time frame. In that case a
scenario I'm trying to address is when one backend with the new NBuffers
value allocates a new buffer and puts it into the buffer lookup table,
where it could become reachable by another backend, which still has the
old NBuffer value. Correct me if I'm wrong, but initializing buffer
headers + updating NBuffers means clock sweep can now return one of
those new buffers, opening the scenario above, right?



pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: pg_overexplain extension name
Next
From: Dmitry Dolgov
Date:
Subject: Re: Changing shared_buffers without restart