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

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Fujii Masao <fujii(at)postgresql(dot)org>, 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-03 00:45:20
Message-ID: CAHGQGwEhtaT6qe5fN--t6HhTwBvBoZUukx-NVPpEMG9uFWHHvw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Fri, Apr 3, 2026 at 4:56 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Wed, Apr 1, 2026 at 2:44 AM Fujii Masao <fujii(at)postgresql(dot)org> wrote:
> > Reduce log level of some logical decoding messages from LOG to DEBUG1
>
> Hi,
>
> Apologies for not having noticed this thread before the patch was
> committed, but I have some reservations about this change.

Thanks for sharing your thoughts!

> I agree
> that if someone is calling pg_logical_slot_get_changes() regularly, it
> isn't good to write a LOG message every time. However, I am concerned
> that this may make problems with regular logical decoding much harder
> to debug. I see that there was some discussion of adding a GUC to
> raise the level back up to LOG, but I feel like that wouldn't help
> much.

Yes, I'm proposing a new GUC, trace_logical_decoding_messages, as discussed
in [1]. I was thinking this GUC would be sufficient for this purpose. With this
GUC, the messages changed to DEBUG1 by this commit could be output at LOG
by default, preserving previous behavior. On the other hand, users who want
less noise could then adjust the setting to suppress those messages. This way,
it would cover both use cases: those who want LOG-level messages for debugging,
and those who prefer to suppress them.

But maybe I'm missing something. It would be helpful to understand what issues
you see with this approach.

> If something goes wrong, enabling the messages for the future
> won't tell you what went wrong in the past. I am wondering whether a
> better approach might be to set the LOG level based on context -- that
> is, if it's actually logical decoding, log this at LOG, but if it's
> just someone peeking at a slot or similar, reduce the log level to
> DEBUG1 or, really, probably more like DEBUG3.

You are suggesting something like that logical walsender and
pg_logical_slot_get_changes() should log at LOG, while the slotsync worker
should use DEBUG? Sorry, I may be misunderstanding, since the slotsync worker
can also use logical decoding mechanism internally. Could you clarify what you
have in mind by "peeking at a slot or similar"?

Regards,

[1] https://postgr.es/m/CAHGQGwFB+hC97SHDpn1vOHHOq9uM5OZZmt50j7v6Z1JUNtH5zQ@mail.gmail.com

--
Fujii Masao

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Thomas Munro 2026-04-03 02:15:26 pgsql: jit: No backport::SectionMemoryManager for LLVM 22.
Previous Message Tom Lane 2026-04-02 21:21:45 pgsql: Further harden tests that might use not-so-compatible tar versio

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2026-04-03 00:47:28 Re: pg_waldump: support decoding of WAL inside tarfile
Previous Message Tom Lane 2026-04-03 00:11:37 Re: pg_waldump: support decoding of WAL inside tarfile