Re: Changing shared_buffers without restart
От | Burd, Greg |
---|---|
Тема | Re: Changing shared_buffers without restart |
Дата | |
Msg-id | 3E802313-89C8-4CE7-A4B5-FB11049E7B2A@burd.me обсуждение исходный текст |
Ответ на | Re: Changing shared_buffers without restart (Dmitry Dolgov <9erthalion6@gmail.com>) |
Ответы |
Re: Changing shared_buffers without restart
|
Список | pgsql-hackers |
> On Jul 14, 2025, at 10:01 AM, Dmitry Dolgov <9erthalion6@gmail.com> 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. 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? Hello, first off thanks for working on the intricate issues related to resizing shared_buffers. Second, I'm new in this code so take that in account but I'm the person trying to remove the freelist entirely [1] so I have reviewed this code recently. I'd initialize them, expand BufferDescriptors, and adjust NBuffers. The clock-sweep algorithm will eventually find them and make use of them. The buf->freeNext should be FREENEXT_NOT_IN_LIST so that StrategyFreeBuffer() will do the work required to append it the freelist after use. AFAICT there is no need to add to the freelist up front. best. -greg [1] https://postgr.es/m/flat/E2D6FCDC-BE98-4F95-B45E-699C3E17BA10%40burd.me
В списке pgsql-hackers по дате отправления: