| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | 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:04:12 |
| Message-ID: | CAHGQGwFf+cpgw3T=NsGF8cxm4zx74AMCdajDda2Z7OXq9YM1mQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
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.
> > 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.
Regards,
[1] https://postgr.es/m/CAHGQGwF6zG9Z8ws1yb3hY1VqV-WT7hR0qyXCn2HdbjvZQKufDw@mail.gmail.com
--
Fujii Masao
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Adjust-log-level-of-logical-decoding-messages-by-.patch | application/octet-stream | 4.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2026-04-07 03:18:02 | Re: pgsql: Reduce log level of some logical decoding messages from LOG to D |
| Previous Message | Michael Paquier | 2026-04-07 03:01:21 | pgsql: Fix shmem allocation of fixed-sized custom stats kind |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-04-07 03:04:35 | Re: Shmem allocated wrong for custom cumulative stats |
| Previous Message | Noah Misch | 2026-04-07 02:42:33 | Re: Adding REPACK [concurrently] |