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 по дате отправления: