Re: Estimating HugePages Requirements? - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: Estimating HugePages Requirements?
Date
Msg-id D0FF2724-7578-4D5F-991A-8052ED71F07C@amazon.com
Whole thread Raw
In response to Re: Estimating HugePages Requirements?  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On 9/5/21, 7:28 PM, "Michael Paquier" <michael@paquier.xyz> wrote:
> On Fri, Sep 03, 2021 at 05:36:43PM +0000, Bossart, Nathan wrote:
>> On 9/2/21, 6:46 PM, "Michael Paquier" <michael@paquier.xyz> wrote:
>>> 0001, that refactors the calculation of the shmem size into a
>>> different routine, is fine as-is, so I'd like to move on and apply
>>> it.
>> 
>> Sounds good to me.
>
> Applied this one.

Thanks!

> Without concluding on 0002 yet, another thing that we could do is to
> just add the GUCs.  These sound rather useful on their own (mixed
> feelings about huge_pages_required but I can see why it is useful to
> avoid the setup steps and the backend already grabs this information),
> particularly when it comes to cloned setups that share a lot of
> properties.

I think this is a good starting point, but I'd like to follow up on
making them visible without completely starting the server.  The main
purpose for adding these GUCs is to be able to set up huge pages
before server startup.  Disallowing "-C huge_pages_required" on a
running server to enable this use-case seems like a modest tradeoff.

Anyway, I'll restructure the remaining patches to add the GUCs first
and then address the 0002 business separately.

Nathan


pgsql-hackers by date:

Previous
From: "kuroda.hayato@fujitsu.com"
Date:
Subject: RE: Allow escape in application_name
Next
From: "tanghy.fnst@fujitsu.com"
Date:
Subject: RE: Added schema level support for publication.