Re: Changing shared_buffers without restart
От | Andres Freund |
---|---|
Тема | Re: Changing shared_buffers without restart |
Дата | |
Msg-id | afnt6ptmwx5zef46wmvxnqa2e57fwh57yg53met3hrbmsswavr@i663vegqqcal обсуждение исходный текст |
Ответ на | Re: Changing shared_buffers without restart (Dmitry Dolgov <9erthalion6@gmail.com>) |
Ответы |
Re: Changing shared_buffers without restart
|
Список | pgsql-hackers |
Hi, On 2025-07-14 15:08:28 +0200, Dmitry Dolgov wrote: > > 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. Are you tell me that you'd put "new" buffers onto the freelist, before you increase NBuffers? That doesn't make sense. Orthogonaly - there's discussion about simply removing the freelist. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: