Re: pgsql: Reduce log level of some logical decoding messages from LOG to D
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-07T03:18:02Z
Lists: pgsql-hackers
On Tue, Apr 7, 2026 at 8:34 AM Fujii Masao <masao.fujii@gmail.com> wrote: > > On Tue, Apr 7, 2026 at 1:16 AM 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 welcome. > How about adding repack_worker to that check as well? See 28d534e2ae. > > > > 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. > > Maybe. One such case is that, due to the issue discussed in [1], the slotsync > worker can generate those messages as frequently as every 200 ms. But once > that is fixed, it emits them only once per sync cycle, with intervals ranging > 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.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Adjust log level of logical decoding messages by context
- de74d1e9a545 19 (unreleased) landed
-
Reduce log level of some logical decoding messages from LOG to DEBUG1
- 21b018e7eab5 19 (unreleased) cited