Re: Logging parallel worker draught

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Logging parallel worker draught
Дата
Msg-id CA+TgmoaSO-9Oh88TarrSCg9=_0HJssCqwsEvMk_2hjfkG0+poA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Logging parallel worker draught  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Logging parallel worker draught  ("Imseih (AWS), Sami" <simseih@amazon.com>)
Список pgsql-hackers
On Tue, May 2, 2023 at 6:57 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> We can output this at the LOG level to avoid running the server at
> DEBUG1 level. There are a few other cases where we are not able to
> spawn the worker or process and those are logged at the LOG level. For
> example, "could not fork autovacuum launcher process .." or "too many
> background workers". So, not sure, if this should get a separate
> treatment. If we fear this can happen frequently enough that it can
> spam the LOG then a GUC may be worthwhile.

I think we should definitely be afraid of that. I am in favor of a separate GUC.

> > What I was wondering was whether we would be better off putting this
> > into the statistics collector, vs. doing it via logging. Both
> > approaches seem to have pros and cons.
>
> I think it could be easier for users to process the information if it
> is available via some view, so there is a benefit in putting this into
> the stats subsystem.

Unless we do this instead.

--
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Melih Mutlu
Дата:
Сообщение: Re: pg_stat_io for the startup process
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: issue with meson builds on msys2