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

From Robert Haas
Subject Re: Changing shared_buffers without restart
Date
Msg-id CA+TgmoZYuoxGiVHK375VfS1Unkt2j0VHuVuT=Jcbv9xrK1F9ng@mail.gmail.com
Whole thread Raw
In response to Re: Changing shared_buffers without restart  (Jelte Fennema-Nio <postgres@jeltef.nl>)
List pgsql-hackers
On Wed, Nov 27, 2024 at 4:28 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> On Wed, 27 Nov 2024 at 22:06, Robert Haas <robertmhaas@gmail.com> wrote:
> > If we had an upper bound on the size of shared_buffers
>
> I think a fairly reliable upper bound is the amount of physical memory
> on the system at time of postmaster start. We could make it a GUC to
> set the upper bound for the rare cases where people do stuff like
> adding swap space later or doing online VM growth. We could even have
> the default be something like 4x the physical memory to accommodate
> those people by default.

Yes, Peter mentioned similar ideas on this thread last week.

> > reserve that amount of address space at startup time but only actually
> > map a portion of it
>
> Or is this the difficult part?

I'm not sure how difficult this is, although I'm pretty sure that it's
more difficult than adding a GUC. My point wasn't so much whether this
is easy or hard but rather that it's essential if you want to avoid
having addresses change when the resizing happens.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation
Next
From: Robert Haas
Date:
Subject: Re: Changing shared_buffers without restart