MIME-Version: 1.0
References: 
 <CAHGQGwGTyHgtD9tyN664x6vQ8Q1G53H7ZUCgBU9_X=nLt3f1QA@mail.gmail.com>
 <CALj2ACX_SSJYKt5od1C2874yeotTO9JewfRY9B=3DYx2daUAMw@mail.gmail.com>
In-Reply-To: 
 <CALj2ACX_SSJYKt5od1C2874yeotTO9JewfRY9B=3DYx2daUAMw@mail.gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
Date: Tue, 24 Mar 2026 00:44:37 +0900
Message-ID: 
 <CAHGQGwHTuLKTmW5DHtx-5yMuEq4=fc7M+UuvdOVekyvfsi=48Q@mail.gmail.com>
Subject: Re: Reduce log level of some logical decoding messages to DEBUG1
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAHGQGwHTuLKTmW5DHtx-5yMuEq4%3Dfc7M%2BUuvdOVekyvfsi%3D48Q%40mail.gmail.com>
Precedence: bulk

On Mon, Mar 23, 2026 at 10:53=E2=80=AFPM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> Hi,
>
> On Mon, Mar 23, 2026 at 1:23=E2=80=AFAM Fujii Masao <masao.fujii@gmail.co=
m> wrote:
> >
> > In logical decoding, messages like the following are currently logged a=
t
> > 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 intereste=
d 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 repea=
tedly,
> > 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.

I agree those messages are useful for developers. Do you think they're also
useful for DBAs, and therefore should remain at LOG level?


> > 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 mess=
ages
> > would be still emitted regularly.
> >
> > Given that these are mostly developer-oriented messages, logging them a=
t
> > LOG level seems too verbose. I'm proposing to reduce their level to DEB=
UG1.
> > A patch is attached.
> >
> > Alternatively, if we want to keep them at LOG by default, we could intr=
oduce
> > a GUC like trace_logical_decoding_messages, similar to
> > the old trace_recovery_messages, to control their verbosity independent=
ly
> > 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?

If we want to see those messages when walsender is performing logical
decoding, that should still be possible even if we lower the level to DEBUG=
1.
With the recent extension to log_min_messages (commit 38e0190ced7),
we can enable them just for walsender
(e.g., log_min_messages =3D 'warning,walsender:debug1').

Regards,

--=20
Fujii Masao