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

From Andres Freund
Subject Re: Changing shared_buffers without restart
Date
Msg-id fkm2z3idtem4raycfvxhuxwytxkugcqhjiryzub2hstjkbjele@cn2v5fzvvj2k
Whole thread Raw
In response to Re: Changing shared_buffers without restart  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: Changing shared_buffers without restart
RE: Changing shared_buffers without restart
List pgsql-hackers
Hi,

On 2025-07-14 16:01:50 +0200, Dmitry Dolgov wrote:
> > On Mon, Jul 14, 2025 at 09:42:46AM -0400, Andres Freund wrote:
> > What on earth would be the point of putting a buffer on the freelist but not
> > make it reachable by the clock sweep? To me that's just nonsensical.
> 
> To clarify, we're not talking about this scenario as "that's how it
> would work after the resize". The point is that to expand shared buffers
> they need to be initialized, included into the whole buffer machinery
> (freelist, clock sweep, etc.) and NBuffers has to be updated.

It seems pretty obvious to that the order has to be

1) initialize buffer headers
2) update NBuffers
3) put them onto the freelist

(with 3) hopefully becoming obsolete)


> 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.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: "Burd, Greg"
Date:
Subject: Re: Changing shared_buffers without restart
Next
From: Tom Lane
Date:
Subject: Re: track needed attributes in plan nodes for executor use