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>
 <CAHGQGwFARNb_2J1Skvw5RQSsyhqUqWQgQJNDhP+v-7fzinLfOw@mail.gmail.com>
In-Reply-To: 
 <CAHGQGwFARNb_2J1Skvw5RQSsyhqUqWQgQJNDhP+v-7fzinLfOw@mail.gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Mon, 6 Apr 2026 12:15:47 -0400
Message-ID: 
 <CA+TgmoZ2+HQess2QSuZp1si17CDHw165PQROaFq0skcKJS20-g@mail.gmail.com>
Subject: Re: pgsql: Reduce log level of some logical decoding messages from
 LOG to D
To: Fujii Masao <masao.fujii@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/CA%2BTgmoZ2%2BHQess2QSuZp1si17CDHw165PQROaFq0skcKJS20-g%40mail.gmail.com>
Precedence: bulk

On Mon, Apr 6, 2026 at 11:57=E2=80=AFAM Fujii Masao <masao.fujii@gmail.com>=
 wrote:
> This seems similar to Bharath's suggestion in [1].

Yes, I think it's the same idea.

> You can already do this by
> setting log_min_messages =3D 'warning,walsender:debug1'. With that settin=
g,
> DEBUG1 logical decoding messages from walsender are logged at LOG, while
> backends follow log_min_messages=3Dwarning, so logical decoding SQL funct=
ions
> 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 mess=
ages
> at LOG when AmWalSenderProcess() or AmLogicalSlotSyncWorkerProcess() is t=
rue,
> and at DEBUG1 otherwise.

Yeah.

> 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 th=
em,
> but would also hide ERROR messages, which isn't desirable in production.

I honestly don't know why anyone would want to do that. If these
messages are showing up from background workers often enough to cause
a problem, isn't something terribly wrong? It probably means your
logical replication connections are constantly getting broken and
having to be reestablished. The premise stated in the commit message
is that these messages are simply too noisy, and that seems fair to
me, because of the possibility of triggering them from SQL. But the
idea that these aren't useful to a DBA when troubleshooting actual
problems with logical replication seems quite incorrect to me.

--
Robert Haas
EDB: http://www.enterprisedb.com