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>
 <CA+TgmoZ2+HQess2QSuZp1si17CDHw165PQROaFq0skcKJS20-g@mail.gmail.com>
 <CAHGQGwFf+cpgw3T=NsGF8cxm4zx74AMCdajDda2Z7OXq9YM1mQ@mail.gmail.com>
In-Reply-To: 
 <CAHGQGwFf+cpgw3T=NsGF8cxm4zx74AMCdajDda2Z7OXq9YM1mQ@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Tue, 7 Apr 2026 08:48:02 +0530
Message-ID: 
 <CAA4eK1+VwGQb5T7xH5AXS0XknGGCAVZQLbBcjq9DZikJhViX2g@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: Robert Haas <robertmhaas@gmail.com>,
	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/CAA4eK1%2BVwGQb5T7xH5AXS0XknGGCAVZQLbBcjq9DZikJhViX2g%40mail.gmail.com>
Precedence: bulk

On Tue, Apr 7, 2026 at 8:34=E2=80=AFAM Fujii Masao <masao.fujii@gmail.com> =
wrote:
>
> On Tue, Apr 7, 2026 at 1:16=E2=80=AFAM Robert Haas <robertmhaas@gmail.com=
> wrote:
> > > But probably are you suggesting making this behavior the default? If =
yes,
> > > one straightforward approach to implement that would be to log these =
messages
> > > at LOG when AmWalSenderProcess() or AmLogicalSlotSyncWorkerProcess() =
is true,
> > > and at DEBUG1 otherwise.
> >
> > Yeah.
>
> OK, I've prepared a patch to implement this. Patch attached.
> It introduces a LogicalDecodingLogLevel() macro to choose the log level
> based on context, but the name may not be ideal, so suggestions are welco=
me.
>

How about adding repack_worker to that check as well? See 28d534e2ae.

>
> > > The downside of this approach is that it becomes harder to suppress t=
hese
> > > messages for walsender or slotsync worker if some users want to do th=
at.
> > > For example, raising log_min_messages to FATAL or PANIC would suppres=
s them,
> > > but would also hide ERROR messages, which isn't desirable in producti=
on.
> >
> > 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.
>
> Maybe. One such case is that, due to the issue discussed in [1], the slot=
sync
> worker can generate those messages as frequently as every 200 ms. But onc=
e
> that is fixed, it emits them only once per sync cycle, with intervals ran=
ging
> from MIN_SLOTSYNC_WORKER_NAPTIME_MS (200 ms) to
> MAX_SLOTSYNC_WORKER_NAPTIME_MS (30 s), which might not generate
> excessive log volume. At that point, it might be OK if messages from
> background activity are not easily suppressible.
>

Yeah, we need to fix that issue.

With Regards,
Amit Kapila.