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 по дате отправления: