Re: Estimating HugePages Requirements?

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Estimating HugePages Requirements?
Дата
Msg-id Yjq9bJe28newGZaK@paquier.xyz
обсуждение исходный текст
Ответ на Re: Estimating HugePages Requirements?  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: Estimating HugePages Requirements?  (Michael Paquier <michael@paquier.xyz>)
Re: Estimating HugePages Requirements?  (Magnus Hagander <magnus@hagander.net>)
Список 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.

>          puts(config_val ? config_val : "");
> +
> +        /* don't emit shutdown messages */
> +        SetConfigOption("log_min_messages", "PANIC", PGC_INTERNAL, PGC_S_OVERRIDE);
> +
>          ExitPostmaster(0);

That's fancy, but I don't like that much.  And this would not protect
either against any messages generated before this code path, either,
even if that should be enough for the current HEAD .

My solution for the docs is perhaps too confusing for the end-user,
and we are talking about a Linux-only thing here anyway.  So, at the
end, I am tempted to just add the "2> /dev/null" as suggested upthread
by Nathan and call it a day.  Does that sound fine?
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)
Следующее
От: Amit Langote
Дата:
Сообщение: Re: ExecRTCheckPerms() and many prunable partitions