Re: log_min_messages per backend type

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: log_min_messages per backend type
Date: 2025-03-05 00:33:39
Message-ID: 313aa202-b5fa-4e3f-95d0-83425575c66d@app.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 5, 2025, at 3:51 PM, Álvaro Herrera wrote:
> On 2024-Dec-17, Euler Taveira wrote:
>
> > Sometimes you need to inspect some debug messages from autovacuum worker but
> > you cannot apply the same setting for backends (that could rapidly fill the log
> > file). This proposal aims to change log_min_messages to have different log
> > levels depending on which backend type the message comes from.
> >
> > The syntax was changed from enum to string and it accepts a list of elements.
> >
> > Instead of enum, it now accepts a comma-separated list of elements (string).
> > Each element is LOGLEVEL:BACKENDTYPE.
>
> This format seems unintuitive. I would have thought you do it the other
> way around, "backendtype:loglevel" ... that seems more natural because
> it's like assigning the 'loglevel' value to the 'backendtype' element.
> SET log_min_messages TO 'checkpointer:debug2, autovacuum:debug1';

Alvaro, thanks for your feedback. Your suggestion makes sense to me.

> I dislike the array of names in variable.c. We already have an array in
> launch_backend.c (child_process_kinds), plus GetBackendTypeDesc in
> miscinit.c. Maybe not for this patch to clean up though.

I thought about using child_process_kinds but two details made me give
up on the idea: (a) multiple names per backend type (for example,
B_BACKEND, B_DEAD_END_BACKEND, B_STANDALONE_BACKEND) and (b) spaces into
names. Maybe we should have a group into child_process_kinds but as you
said it seems material for another patch.

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

> Also, I think it'd be better to reject duplicates in the list. Right
> now it looks like the last entry for one backend type overrides prior
> ones. I mean
>
> log_min_messages = autovacuum:DEBUG1, autovacuum:ERROR
>
> would set autovacuum to error, but that might be mistake prone if your
> string is long. So implementation-wise I suggest to initialize the
> whole newlogminmsgs array to -1, then scan the list of entries (saving
> an entry without backend type as the one to use later and) setting every
> backend type to the number specified; if we see trying to set a value
> that's already different from -1, throw error. After scanning the whole
> log_min_messages array, we scan the newlogminmsgs and set any entries
> that are still -1 to the value that we saved before.
>
>
> The new code in variable.c should be before the /* DATESTYLE */ comment
> rather than at the end of the file.

It was added into the MISCELLANEOUS section.

>
> You still have many XXX comments. Also, postgresql.conf should list the
> valid values for backendtype, as well as show an example of a valid
> setting. Please don't use ALLCAPS backend types in the docs, this looks
> ugly:
>
> > + Valid <literal>BACKENDTYPE</literal> values are <literal>ARCHIVER</literal>,
> > + <literal>AUTOVACUUM</literal>, <literal>BACKEND</literal>,
> > + <literal>BGWORKER</literal>, <literal>BGWRITER</literal>,
> > + <literal>CHECKPOINTER</literal>, <literal>LOGGER</literal>,
> > + <literal>SLOTSYNCWORKER</literal>, <literal>WALRECEIVER</literal>,
> > + <literal>WALSENDER</literal>, <literal>WALSUMMARIZER</literal>, and
> > + <literal>WALWRITER</literal>.

Done.

Just to recap what was changed:

- patch was rebased
- backend type is optional and means all unspecified backend types
- generic log level (without backend type) is mandatory and the order it
ppears is not important (it is applied for the remaining backend types)
- fix Windows build
- new tests to cover the changes

--
Euler Taveira
EDB https://www.enterprisedb.com/

Attachment Content-Type Size
v2-0001-log_min_messages-per-backend-type.patch text/x-patch 21.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-03-05 00:41:38 Re: Flaky 003_start_stop.pl test
Previous Message Fujii Masao 2025-03-05 00:32:00 Re: [PATCH] Add regression tests of ecpg command notice (error / warning)