Re: Changing shared_buffers without restart

On Tue, Feb 10, 2026 at 6:32 AM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
[..]
> > > To resize a shared memory segment in this layout it's possible to use
> > > ftruncate on the memory mapped file.
> > >
> > > This approach also do not impact the actual memory usage as reported by
> > > the kernel.
> >
> > I still don't see what the point of having multiple mappings and using memfd
> > is. We need to reserve the address space for the maximum sized allocation in
> > postmaster, otherwise there's absolutely no guarantee that it's available at
> > those addresses in all the children - which you do as you explain
> > here. Therefore, the maximum size of each "suballocation" needs to be reserved
> > ahead of time. At which point I don't see the point of having multiple
> > mmaps. It just makes things more complicated and expensive (each mmap makes
> > fork & exit slower).
> >
> > Even if we decide to use memfd, because we consider MADV_DONTNEED to not be
> > suitable for some reason, what's the point of having more than one mapping
> > using memfd?
>
> There are just two mappings now compared to 6 earlier. If I am reading
> Jakub's benchmarking correctly, even 6 segments didn't show much
> regression in his benchmarks. Having just two should not see much
> regression. If we use multiple mappings we could control the
> properties of each segment separately - e.g. use huge pages for some
> (buffer blocks) and not for others.

FWIW, Tomas ended up technically using multiple mmap segments too due to NUMA
and there appears to be no other way (2*NUMA nodes, for at least
Buffer Blocks and
PGPROC as I remember, or maybe it was even 3*nodes??). I hope we
attack that problem
again one day and we can measure the impact again there if needed.

-J.