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

From Bossart, Nathan
Subject Re: Estimating HugePages Requirements?
Date
Msg-id 907F88C0-54F6-4E4A-A4D0-2DB2353AA749@amazon.com
Whole thread Raw
In response to Re: Estimating HugePages Requirements?  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On 8/27/21, 7:41 AM, "Magnus Hagander" <magnus@hagander.net> wrote:
> On Fri, Aug 27, 2021 at 8:46 AM Michael Paquier <michael@paquier.xyz> wrote:
>> On Wed, Aug 11, 2021 at 11:23:52PM +0000, Bossart, Nathan wrote:
>> > While testing this new option, I noticed that you can achieve similar
>> > results today with the following command, although this one will
>> > actually try to create the shared memory, too.
>>
>> That may not be the best option.
>
> I would say that can be a disastrous option.
>
> First of all it would probably not work if you already have something
> running -- especially when using huge pages. And if it does work, in
> that or other scenarios, it can potentially have significant impact on
> a running cluster to suddenly allocate many GB of more memory...

The v3 patch actually didn't work if the server was already running.
I removed that restriction in v4.

>> > IMO the new option is still handy, but I can see the argument that it
>> > might not be necessary.
>>
>> A separate option looks handy.  Wouldn't it be better to document it
>> in postgres-ref.sgml then?
>
> I'd say a lot more than just handy. I don't think the workaround is
> really all that useful.

I added some documentation in v4.

Nathan  


Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: log_autovacuum in Postgres 14 -- ordering issue
Next
From: David Christensen
Date:
Subject: Re: [PATCH] Proof of concept for GUC improvements