Re: Reduce log level of some logical decoding messages to DEBUG1

Hi,

On Mon, Mar 23, 2026 at 1:23 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> In logical decoding, messages like the following are currently logged at
> LOG level:
>
> LOG: starting logical decoding for slot "myslot"
> DETAIL: Streaming transactions committing after 0/030872C0,
> reading WAL from 0/03087288.
> STATEMENT: ...
> LOG: logical decoding found consistent point at 0/03087288
> DETAIL: There are no running transactions.
> STATEMENT: ...
>
> These can be useful for debugging, but DBAs are typically not interested in
> them. They can also be emitted frequently, for example, on each call to
> functions like pg_logical_slot_peek_binary_changes() or
> pg_replication_slot_advance() etc. When such functions are called repeatedly,
> the logs can quickly become noisy.

I understand the chattiness of these when the decoding is done using
functions. But they seem to be useful when decoding using walsender
and replication connection. Also, it looks to me that the errdetail
describing various cases like when there are no running transactions,
when logical decoding will begin using saved snapshot, etc., is
helpful.

> The slotsync worker can also generate these messages periodically. Due to
> the issue discussed at [1], this can currently happen as often as every 200ms
> (which should be fixed separately). Even without that issue, these messages
> would be still emitted regularly.
>
> Given that these are mostly developer-oriented messages, logging them at
> LOG level seems too verbose. I'm proposing to reduce their level to DEBUG1.
> A patch is attached.
>
> Alternatively, if we want to keep them at LOG by default, we could introduce
> a GUC like trace_logical_decoding_messages, similar to
> the old trace_recovery_messages, to control their verbosity independently
> of log_min_messages.
>
> Thought?

1 for another GUC IMHO. How about we find if the logical decoding is
being done using walsender (a boolean like isDecodingUsingWalSender,
default being false, set to true when in walsender) and emit them at
LOG level when set to true. Would something like this work?

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com