Re: Changing shared_buffers without restart
От | Andres Freund |
---|---|
Тема | Re: Changing shared_buffers without restart |
Дата | |
Msg-id | ndv2aa7z6qxzp7xehoqi4xz2sujfm4mgwictalr5ovtfhwv2pp@fjzdg5pj3r6t обсуждение исходный текст |
Ответ на | Re: Changing shared_buffers without restart (Dmitry Dolgov <9erthalion6@gmail.com>) |
Ответы |
Re: Changing shared_buffers without restart
|
Список | pgsql-hackers |
Hi, On 2025-07-14 11:32:25 +0200, Dmitry Dolgov wrote: > > 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. Clock sweep can find any buffer, independent of whether it's on the freelist.
В списке pgsql-hackers по дате отправления: