MIME-Version: 1.0
References: <E1w7pJ5-002Q6p-10@gemulon.postgresql.org>
 <CA+TgmoYsu2+YAo9eLGkDp5VP-pfQ-jOoX382vS4THKHeRTNgew@mail.gmail.com>
 <CAHGQGwEhtaT6qe5fN--t6HhTwBvBoZUukx-NVPpEMG9uFWHHvw@mail.gmail.com>
 <CA+TgmoYwebE37qZwcNE9MKT4rt3ymP2s1M6KyRK_MGkxCYZMeg@mail.gmail.com>
In-Reply-To: 
 <CA+TgmoYwebE37qZwcNE9MKT4rt3ymP2s1M6KyRK_MGkxCYZMeg@mail.gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
Date: Tue, 7 Apr 2026 00:57:26 +0900
Message-ID: 
 <CAHGQGwFARNb_2J1Skvw5RQSsyhqUqWQgQJNDhP+v-7fzinLfOw@mail.gmail.com>
Subject: Re: pgsql: Reduce log level of some logical decoding messages from
 LOG to D
To: Robert Haas <robertmhaas@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/CAHGQGwFARNb_2J1Skvw5RQSsyhqUqWQgQJNDhP%2Bv-7fzinLfOw%40mail.gmail.com>
Precedence: bulk

On Mon, Apr 6, 2026 at 11:55=E2=80=AFPM Robert Haas <robertmhaas@gmail.com>=
 wrote:
>
> On Thu, Apr 2, 2026 at 8:45=E2=80=AFPM Fujii Masao <masao.fujii@gmail.com=
> wrote:
> > > If something goes wrong, enabling the messages for the future
> > > won't tell you what went wrong in the past. I am wondering whether a
> > > better approach might be to set the LOG level based on context -- tha=
t
> > > is, if it's actually logical decoding, log this at LOG, but if it's
> > > just someone peeking at a slot or similar, reduce the log level to
> > > DEBUG1 or, really, probably more like DEBUG3.
> >
> > You are suggesting something like that logical walsender and
> > pg_logical_slot_get_changes() should log at LOG, while the slotsync wor=
ker
> > should use DEBUG? Sorry, I may be misunderstanding, since the slotsync =
worker
> > can also use logical decoding mechanism internally. Could you clarify w=
hat you
> > have in mind by "peeking at a slot or similar"?
>
> No, what I mean is that if someone runs an SQL function from the
> foreground, they probably don't want that to result in a LOG message,
> but if background activity results in such a message, the LOG message
> is probably a good idea. The reasons are:
>
> 1. Somebody might run many foreground queries that rely on the logical
> decoding infrastructure, so logging something every time such a query
> is executed could produce a lot of log spam. But there shouldn't be so
> much background logical decoding for this to be an issue.
>
> 2. If logical replication is not working, that may be a major issue
> for the DBA. A problem running pg_logical_slot_get_changes() is likely
> not as critical (and if it is, they can always lower
> client_min_messages or log_min_messages for that session only).

This seems similar to Bharath's suggestion in [1]. You can already do this =
by
setting log_min_messages =3D 'warning,walsender:debug1'. With that setting,
DEBUG1 logical decoding messages from walsender are logged at LOG, while
backends follow log_min_messages=3Dwarning, so logical decoding SQL functio=
ns
don't emit those DEBUG1 messages.

But probably are you suggesting making this behavior the default? If yes,
one straightforward approach to implement that would be to log these messag=
es
at LOG when AmWalSenderProcess() or AmLogicalSlotSyncWorkerProcess() is tru=
e,
and at DEBUG1 otherwise.

The downside of this approach is that it becomes harder to suppress these
messages for walsender or slotsync worker if some users want to do that.
For example, raising log_min_messages to FATAL or PANIC would suppress them=
,
but would also hide ERROR messages, which isn't desirable in production.

Regards,

[1] https://postgr.es/m/CALj2ACX_SSJYKt5od1C2874yeotTO9JewfRY9B=3D3DYx2daUA=
Mw@mail.gmail.com

--=20
Fujii Masao