Just brain-storming here... would moving NBuffers to shared memory solve this specific issue? Though I'm pretty sure that would open up a new set of synchronization issues elsewhere, so I'm not sure if there's a net gain.
Jack >-----Original Message----- >From: Andres Freund <[email protected]> >Sent: Monday, July 14, 2025 11:12 AM >To: Dmitry Dolgov <[email protected]> >Cc: Thom Brown <[email protected]>; Ashutosh Bapat ><[email protected]>; Tomas Vondra <[email protected]>; >Thomas Munro <[email protected]>; PostgreSQL-development <pgsql- >[email protected]>; Jack Ng <[email protected]>; Ni Ku ><[email protected]> >Subject: Re: Changing shared_buffers without restart > >Hi, > >On July 14, 2025 10:39:33 AM EDT, Dmitry Dolgov <[email protected]> >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. > >Andres >-- >Sent from my Android device with K-9 Mail. Please excuse my brevity.
