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

From Dmitry Dolgov
Subject Re: Changing shared_buffers without restart
Date
Msg-id 7ohqbhtw7m6obker4r6rgf53awrd2trupeai4ihwizev565jd4@cro4alc7fahc
Whole thread Raw
In response to Re: Changing shared_buffers without restart  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
> On Mon, Jul 14, 2025 at 11:11:36AM -0400, Andres Freund wrote:
> Hi,
>
> On July 14, 2025 10:39:33 AM EDT, Dmitry Dolgov <9erthalion6@gmail.com> wrote:
> >> 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?
>
> The same is true if you put buffers into the freelist.

Yep, but the question about clock sweep still stays. Anyway, thanks for
the input, let me digest it and come up with more questions & patch
series.



pgsql-hackers by date:

Previous
From: Jack Ng
Date:
Subject: RE: Changing shared_buffers without restart
Next
From: Xuneng Zhou
Date:
Subject: Re: Add progressive backoff to XactLockTableWait functions