Re: Changing shared_buffers without restart
От | Dmitry Dolgov |
---|---|
Тема | Re: Changing shared_buffers without restart |
Дата | |
Msg-id | kgytdkyohq4kw7p2r7vvp64wuaerpb7r65yminhqvffbdyn7eh@67wvb6kbjqwp обсуждение исходный текст |
Ответ на | Re: Changing shared_buffers without restart (Ni Ku <jakkuniku@gmail.com>) |
Ответы |
Re: Changing shared_buffers without restart
|
Список | pgsql-hackers |
> On Fri, Mar 21, 2025 at 04:48:30PM GMT, Ni Ku wrote: > Thanks for your insights and confirmation, Dmitry. > Right, I think the anonymous fd approach would work to keep the memory > contents intact in between munmap and mmap with the new size, so bufferpool > expansion would work. > But it seems shrinking would still be problematic, since that approach > requires the anonymous fd to remain open (for memory content protection), > and so munmap would not release the memory back to the OS right away (gets > released when the fd is closed). From testing this is true for hugepage > memory at least. > Is there a way around this? Or maybe I misunderstood what you have in mind > ;) The anonymous file will be truncated to it's new shrinked size before mapping it second time (I think this part is missing in your test example), to my understanding after a quick look at do_vmi_align_munmap, this should be enough to make the memory reclaimable.
В списке pgsql-hackers по дате отправления: