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

From Amit Kapila
Subject Re: Logging parallel worker draught
Date
Msg-id CAA4eK1LTDCgT0Up8TtyX+0gC_KKRCq+oCKxcwPT0k6QcpGCy8w@mail.gmail.com
Whole thread Raw
In response to Re: Logging parallel worker draught  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Logging parallel worker draught
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PoC] pg_upgrade: allow to upgrade publisher node
Next
From: "Drouvot, Bertrand"
Date:
Subject: Re: Add two missing tests in 035_standby_logical_decoding.pl