Re: Estimating HugePages Requirements?

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Don Seiler <don(at)seiler(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Estimating HugePages Requirements?
Date: 2022-03-21 22:12:05
Message-ID: 20220321221205.GA1514705@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

On Tue, Mar 15, 2022 at 03:44:39PM -0700, Nathan Bossart wrote:
> A simple approach could be to just set log_min_messages to PANIC before
> exiting. I've attached a patch for this. With this patch, we'll still see
> a FATAL if we try to use 'postgres -C' for a runtime-computed GUC on a
> running server, and there will be no extra output as long as the user sets
> log_min_messages to INFO or higher (i.e., not a DEBUG* value). For
> comparison, 'postgres -C' for a non-runtime-computed GUC does not emit
> extra output as long as the user sets log_min_messages to DEBUG2 or higher.

I created a commitfest entry for this:

https://commitfest.postgresql.org/38/3596/

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Michel SALAIS 2022-03-21 22:37:13 RE: How to check existing recovery points
Previous Message Guillaume Lelarge 2022-03-21 14:19:47 Re: How to check existing recovery points

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2022-03-21 22:13:18 Re: freeing bms explicitly
Previous Message Tom Lane 2022-03-21 22:05:19 Re: freeing bms explicitly