Re: Changing shared_buffers without restart - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: Changing shared_buffers without restart
Date
Msg-id kgytdkyohq4kw7p2r7vvp64wuaerpb7r65yminhqvffbdyn7eh@67wvb6kbjqwp
Whole thread Raw
In response to Re: Changing shared_buffers without restart  (Ni Ku <jakkuniku@gmail.com>)
Responses Re: Changing shared_buffers without restart
List 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 by date:

Previous
From: Richard Guo
Date:
Subject: Reduce "Var IS [NOT] NULL" quals during constant folding
Next
From: Jim Jones
Date:
Subject: Re: [PATCH] Add CANONICAL option to xmlserialize