| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pgsql: Reduce log level of some logical decoding messages from LOG to D |
| Date: | 2026-04-07 03:18:02 |
| Message-ID: | CAA4eK1+VwGQb5T7xH5AXS0XknGGCAVZQLbBcjq9DZikJhViX2g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On Tue, Apr 7, 2026 at 8:34 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Tue, Apr 7, 2026 at 1:16 AM Robert Haas <robertmhaas(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2026-04-07 03:32:54 | Re: pgsql: Reduce log level of some logical decoding messages from LOG to D |
| Previous Message | Fujii Masao | 2026-04-07 03:04:12 | Re: pgsql: Reduce log level of some logical decoding messages from LOG to D |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-04-07 03:31:04 | Re: Implement waiting for wal lsn replay: reloaded |
| Previous Message | Haibo Yan | 2026-04-07 03:12:04 | Re: Extract numeric filed in JSONB more effectively |