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 <and...@anarazel.de> >Sent: Monday, July 14, 2025 11:12 AM >To: Dmitry Dolgov <9erthali...@gmail.com> >Cc: Thom Brown <t...@linux.com>; Ashutosh Bapat ><ashutosh.bapat....@gmail.com>; Tomas Vondra <to...@vondra.me>; >Thomas Munro <thomas.mu...@gmail.com>; PostgreSQL-development <pgsql- >hack...@postgresql.org>; Jack Ng <jack...@huawei.com>; Ni Ku ><jakkun...@gmail.com> >Subject: Re: Changing shared_buffers without restart > >Hi, > >On July 14, 2025 10:39:33 AM EDT, Dmitry Dolgov <9erthali...@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. > >Andres >-- >Sent from my Android device with K-9 Mail. Please excuse my brevity.
