Re: Changing shared_buffers without restart
От | Dmitry Dolgov |
---|---|
Тема | Re: Changing shared_buffers without restart |
Дата | |
Msg-id | s2eqkawv2m3knhtr32cut6zvyebas25cszpnmlh6amjw6fjjzf@jyzij4mrquqa обсуждение исходный текст |
Ответ на | Re: Changing shared_buffers without restart (Thom Brown <thom@linux.com>) |
Ответы |
Re: Changing shared_buffers without restart
|
Список | pgsql-hackers |
> On Mon, Jul 14, 2025 at 10:24:50AM +0100, Thom Brown wrote: > On Mon, 14 Jul 2025, 09:54 Dmitry Dolgov, <9erthalion6@gmail.com> wrote: > > > > On Mon, Jul 14, 2025 at 01:55:39PM +0530, Ashutosh Bapat wrote: > > > > You're right of course, a buffer id could be returned from the > > > > ClockSweep and from the custom strategy buffer ring. Buf from what I > > see > > > > those are picking a buffer from the set of already utilized buffers, > > > > meaning that for a buffer to land there it first has to go through > > > > StrategyControl->firstFreeBuffer, and hence the idea above will be a > > > > requirement for those as well. > > > > > > That isn't true. A buffer which was never in the free list can still > > > be picked up by clock sweep. > > > > How's that? > > > > Isn't it its job to find usable buffers from the used buffer list when no > free ones are available? The next victim buffer can be selected (and > cleaned if dirty) and then immediately used without touching the free list. Ah, I see what you mean folks. But I'm talking here only about buffers which will be allocated after extending shared memory -- they must go through the freelist first (I don't see why not, any other options?), and clock sweep will have a chance to pick them up only afterwards. That makes the freelist sort of an entry point for those buffers.
В списке pgsql-hackers по дате отправления: