Re: Changing shared_buffers without restart
От | Dmitry Dolgov |
---|---|
Тема | Re: Changing shared_buffers without restart |
Дата | |
Msg-id | x3e2bcy6syxqc3z6jt5pkazegg2ropitvrizn5c3rx2r4askx5@w2vq4uwddv5f обсуждение исходный текст |
Ответ на | Re: Changing shared_buffers without restart (Konstantin Knizhnik <knizhnik@garret.ru>) |
Список | pgsql-hackers |
> On Fri, Apr 18, 2025 at 10:06:23AM GMT, Konstantin Knizhnik wrote: > The only drawback is that we are loosing content of shared buffers in case > of resize. It may be sadly, but not looks like there is no better > alternative. No, why would we loose the content? If we do mremap, it will leave the content as it is. If we do munmap/mmap with an anonymous backing file, it will also keep the content in memory. The same with another proposal about using ftruncate/fallocate only, both will leave the content untouch unless told to do otherwise. > But there are still some dependencies on shared buffers size which are not > addressed in this PR. > I am not sure how critical they are and is it possible to do something here, > but at least I want to enumerate them: Righ, I'm aware about those (except the AIO one, which was added after the first version of the patch), and didn't address them yet due to the same reason you've mentioned -- they're not hard errors, rather inefficiencies. But thanks for the reminder, I keep those in the back of my mind, and when the rest of the design will be settled down, I'll try to address them as well.
В списке pgsql-hackers по дате отправления: