public inbox for [email protected]
help / color / mirror / Atom feedFrom: Fujii Masao <[email protected]>
To: Robert Haas <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: pgsql: Reduce log level of some logical decoding messages from LOG to D
Date: Fri, 3 Apr 2026 09:45:20 +0900
Message-ID: <CAHGQGwEhtaT6qe5fN--t6HhTwBvBoZUukx-NVPpEMG9uFWHHvw@mail.gmail.com> (raw)
In-Reply-To: <CA+TgmoYsu2+YAo9eLGkDp5VP-pfQ-jOoX382vS4THKHeRTNgew@mail.gmail.com>
References: <[email protected]>
<CA+TgmoYsu2+YAo9eLGkDp5VP-pfQ-jOoX382vS4THKHeRTNgew@mail.gmail.com>
On Fri, Apr 3, 2026 at 4:56 AM Robert Haas <[email protected]> wrote:
>
> On Wed, Apr 1, 2026 at 2:44 AM Fujii Masao <[email protected]> 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
view thread (15+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: pgsql: Reduce log level of some logical decoding messages from LOG to D
In-Reply-To: <CAHGQGwEhtaT6qe5fN--t6HhTwBvBoZUukx-NVPpEMG9uFWHHvw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox