Re: pgsql: Reduce log level of some logical decoding messages from LOG to D

On Mon, Apr 6, 2026 at 11:57 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)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 = 'warning,walsender:debug1'. With that setting,
> DEBUG1 logical decoding messages from walsender are logged at LOG, while
> backends follow log_min_messages=warning, so logical decoding SQL functions
> 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 messages
> at LOG when AmWalSenderProcess() or AmLogicalSlotSyncWorkerProcess() is true,
> 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 them,
> 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