Re: Changing shared_buffers without restart
От | Dmitry Dolgov |
---|---|
Тема | Re: Changing shared_buffers without restart |
Дата | |
Msg-id | pdhm6tcvwhmnodv7rnmev2ikd2jy47f72rnygt6majew2at62o@6ac7byvkpiko обсуждение исходный текст |
Ответ на | Re: Changing shared_buffers without restart (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Changing shared_buffers without restart
|
Список | pgsql-hackers |
> On Mon, Jul 14, 2025 at 08:56:56AM -0400, Andres Freund wrote: > > 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. It does the search based on nextVictimBuffer, where the actual buffer will be a modulo of NBuffers, right? If that's correct and I get everything else right, that would mean as long as NBuffers stays the same (which is the case for the purposes of the current discussion) new buffers, allocated on top of NBuffers after shared memory increase, will not be picked by the clock sweep.
В списке pgsql-hackers по дате отправления: