Re: Logging parallel worker draught - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Logging parallel worker draught
Date
Msg-id CA+TgmoaSO-9Oh88TarrSCg9=_0HJssCqwsEvMk_2hjfkG0+poA@mail.gmail.com
Whole thread Raw
In response to Re: Logging parallel worker draught  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Logging parallel worker draught
List 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 by date:

Previous
From: Melih Mutlu
Date:
Subject: Re: pg_stat_io for the startup process
Next
From: Andrew Dunstan
Date:
Subject: Re: issue with meson builds on msys2