Re: log_min_messages per backend type - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: log_min_messages per backend type
Date
Msg-id 001f81e3-2be8-46ad-9aee-1a761686712c@dunslane.net
Whole thread Raw
In response to Re: log_min_messages per backend type  ("Euler Taveira" <euler@eulerto.com>)
List pgsql-hackers


On 2025-03-04 Tu 7:33 PM, Euler Taveira wrote:
I think it should be acceptable to configure one global setting with
exceptions for particular backend types:

log_min_messages = WARNING, autovacuum:DEBUG1

Right now I think the code only accepts the unadorned log level if there
are no other items in the list.  I think the proposal downthread is to
use the keyword ALL for this,

  log_min_messages = all:WARNING, autovacuum:DEBUG1   # I don't like this

but I think it's inferior, because then "all" is not really "all", and I
think it would be different if I had said

  log_min_messages = autovacuum:DEBUG1, all:WARNING   # I don't like this

because it looks like the "all" entry should override the one I set for
autovacuum before, which frankly would not make sense to me.

Good point. After reflection, I agree that "all" is not a good keyword.
This patch turns backend type as optional so WARNING means apply this
log level as a final step to the backend types that are not specified in
the list.

So I think these two lines,

log_min_messages = WARNING, autovacuum:DEBUG1
log_min_messages = autovacuum:DEBUG1, WARNING

should behave identically and mean "set the level for autovacuum to
DEBUG1, and to any other backend type to WARNING.

Done.


Just bikeshedding a bit ...

I'm not mad keen on this design. I think the value should be either a single setting like "WARNING" or a set of type:setting pairs. I agree that "all" is a bad name, but I think "default" would make sense.

I can live with it but I think this just looks a bit odd.


cheers


andrew



--
Andrew Dunstan
EDB: https://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Use Python "Limited API" in PL/Python
Next
From: Tom Lane
Date:
Subject: Re: Allow LISTEN on patterns