Re: Estimating HugePages Requirements?

Поиск
Список
Период
Сортировка
От Nathan Bossart
Тема Re: Estimating HugePages Requirements?
Дата
Msg-id 20220315224439.GA1133771@nathanxps13
обсуждение исходный текст
Ответ на Re: Estimating HugePages Requirements?  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: Estimating HugePages Requirements?  (Nathan Bossart <nathandbossart@gmail.com>)
Re: Estimating HugePages Requirements?  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Tue, Mar 15, 2022 at 11:02:37PM +0100, Magnus Hagander wrote:
> I think we're talking about two different things here.
> 
> I think the "avoid extra logging" would be worth seeing if we can
> address for 15.

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.

> The "able to run on a live cluster" seems a lot bigger and more scary
> and not 15 material.

+1

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

Вложения

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

Предыдущее
От: Yura Sokolov
Дата:
Сообщение: Re: BufferAlloc: don't take two simultaneous locks
Следующее
От: Matthias van de Meent
Дата:
Сообщение: Re: Non-replayable WAL records through overflows and >MaxAllocSize lengths