Re: Logging parallel worker draught

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Logging parallel worker draught
Дата
Msg-id CAA4eK1LTDCgT0Up8TtyX+0gC_KKRCq+oCKxcwPT0k6QcpGCy8w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Logging parallel worker draught  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Logging parallel worker draught  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, May 1, 2023 at 10:03 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Sat, Apr 22, 2023 at 7:06 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > I don't think introducing a GUC for this is a good idea. We can
> > directly output this message in the server log either at LOG or DEBUG1
> > level.
>
> Why not? It seems like something some people might want to log and
> others not. Running the whole server at DEBUG1 to get this information
> doesn't seem like a suitable answer.
>

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.

> 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.

--
With Regards,
Amit Kapila.



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [PoC] pg_upgrade: allow to upgrade publisher node
Следующее
От: "Drouvot, Bertrand"
Дата:
Сообщение: Re: Add two missing tests in 035_standby_logical_decoding.pl