Horton

Re: Changing shared_buffers without restart

Ni Ku <jakkuniku@gmail.com>

View thread
From: Ni Ku <jakkuniku@gmail.com>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>
Date: 2025-03-21T10:30:47Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove PG_MMAP_FLAGS from mem.h

  2. Improve runtime and output of tests for replication slots checkpointing.

  3. Revert support for improved tracking of nested queries

  4. Use exported symbols list on macOS for loadable modules as well

  5. Add support for basic NUMA awareness

  6. Avoid unnecessary copying of a string in pg_restore.c

  7. aio: Infrastructure for io_method=worker

  8. Improve InitShmemAccess() prototype

You're right Dmitry, truncating the anonymous file before mapping it again
does the trick! I see 'HugePages_Free' increases to the expected size right
after the ftruncate call for shrinking.
This alternative approach looks very promising. Thanks.

Regards,

Jack Ng

On Fri, Mar 21, 2025 at 5:31 PM Dmitry Dolgov <9erthalion6@gmail.com> wrote:

> > 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.
>