Reduce log level of some logical decoding messages to DEBUG1

Hi,

On Mon, Mar 23, 2026 at 1:23 AM Fujii Masao <masao.fujii@gmail.com> wrote:

In logical decoding, messages like the following are currently logged at
LOG level:

LOG: starting logical decoding for slot "myslot"
DETAIL: Streaming transactions committing after 0/030872C0,
reading WAL from 0/03087288.
STATEMENT: ...
LOG: logical decoding found consistent point at 0/03087288
DETAIL: There are no running transactions.
STATEMENT: ...

These can be useful for debugging, but DBAs are typically not interested in
them. They can also be emitted frequently, for example, on each call to
functions like pg_logical_slot_peek_binary_changes() or
pg_replication_slot_advance() etc. When such functions are called repeatedly,
the logs can quickly become noisy.

I understand the chattiness of these when the decoding is done using
functions. But they seem to be useful when decoding using walsender
and replication connection. Also, it looks to me that the errdetail
describing various cases like when there are no running transactions,
when logical decoding will begin using saved snapshot, etc., is
helpful.

The slotsync worker can also generate these messages periodically. Due to
the issue discussed at [1], this can currently happen as often as every 200ms
(which should be fixed separately). Even without that issue, these messages
would be still emitted regularly.

Given that these are mostly developer-oriented messages, logging them at
LOG level seems too verbose. I'm proposing to reduce their level to DEBUG1.
A patch is attached.

Alternatively, if we want to keep them at LOG by default, we could introduce
a GUC like trace_logical_decoding_messages, similar to
the old trace_recovery_messages, to control their verbosity independently
of log_min_messages.

Thought?

1 for another GUC IMHO. How about we find if the logical decoding is
being done using walsender (a boolean like isDecodingUsingWalSender,
default being false, set to true when in walsender) and emit them at
LOG level when set to true. Would something like this work?

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

On Mon, Mar 23, 2026 at 10:53 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:

Hi,

On Mon, Mar 23, 2026 at 1:23 AM Fujii Masao <masao.fujii@gmail.com> wrote:

In logical decoding, messages like the following are currently logged at
LOG level:

LOG: starting logical decoding for slot "myslot"
DETAIL: Streaming transactions committing after 0/030872C0,
reading WAL from 0/03087288.
STATEMENT: ...
LOG: logical decoding found consistent point at 0/03087288
DETAIL: There are no running transactions.
STATEMENT: ...

These can be useful for debugging, but DBAs are typically not interested in
them. They can also be emitted frequently, for example, on each call to
functions like pg_logical_slot_peek_binary_changes() or
pg_replication_slot_advance() etc. When such functions are called repeatedly,
the logs can quickly become noisy.

I understand the chattiness of these when the decoding is done using
functions. But they seem to be useful when decoding using walsender
and replication connection. Also, it looks to me that the errdetail
describing various cases like when there are no running transactions,
when logical decoding will begin using saved snapshot, etc., is
helpful.

I agree those messages are useful for developers. Do you think they're also
useful for DBAs, and therefore should remain at LOG level?

The slotsync worker can also generate these messages periodically. Due to
the issue discussed at [1], this can currently happen as often as every 200ms
(which should be fixed separately). Even without that issue, these messages
would be still emitted regularly.

Given that these are mostly developer-oriented messages, logging them at
LOG level seems too verbose. I'm proposing to reduce their level to DEBUG1.
A patch is attached.

Alternatively, if we want to keep them at LOG by default, we could introduce
a GUC like trace_logical_decoding_messages, similar to
the old trace_recovery_messages, to control their verbosity independently
of log_min_messages.

Thought?

1 for another GUC IMHO. How about we find if the logical decoding is
being done using walsender (a boolean like isDecodingUsingWalSender,
default being false, set to true when in walsender) and emit them at
LOG level when set to true. Would something like this work?

If we want to see those messages when walsender is performing logical
decoding, that should still be possible even if we lower the level to DEBUG1.
With the recent extension to log_min_messages (commit 38e0190ced7),
we can enable them just for walsender
(e.g., log_min_messages = 'warning,walsender:debug1').

Regards,

--
Fujii Masao

Hi,

On Mon, Mar 23, 2026 at 8:44 AM Fujii Masao <masao.fujii@gmail.com> wrote:

I understand the chattiness of these when the decoding is done using
functions. But they seem to be useful when decoding using walsender
and replication connection. Also, it looks to me that the errdetail
describing various cases like when there are no running transactions,
when logical decoding will begin using saved snapshot, etc., is
helpful.

I agree those messages are useful for developers. Do you think they're also
useful for DBAs, and therefore should remain at LOG level?

- 1 for another GUC IMHO. How about we find if the logical decoding is
being done using walsender (a boolean like isDecodingUsingWalSender,
default being false, set to true when in walsender) and emit them at
LOG level when set to true. Would something like this work?

If we want to see those messages when walsender is performing logical
decoding, that should still be possible even if we lower the level to DEBUG1.
With the recent extension to log_min_messages (commit 38e0190ced7),
we can enable them just for walsender
(e.g., log_min_messages = 'warning,walsender:debug1').

I agree with this. One could use the new log_min_messages feature
introduced in PG19 if wanted. Perhaps, it's a good idea to add this
recommendation to the commit message to help those wanting to enable
these logs.

I reviewed the v1 patch and it LGTM. Thanks!

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

On Tue, Mar 24, 2026 at 12:44 AM Fujii Masao <masao.fujii@gmail.com> wrote:

Alternatively, if we want to keep them at LOG by default, we could introduce
a GUC like trace_logical_decoding_messages, similar to
the old trace_recovery_messages, to control their verbosity independently
of log_min_messages.

Just in case where many users still want to see those log messages at LOG level,
I also created a second patch (0002) that introduces a new GUC,
trace_logical_decoding_messages, to control logging of logical
decoding debug messages (e.g., "logical decoding found consistent point").

With the default setting (DEBUG1 for now), these messages are effectively
logged at LOG level. Setting it to LOG suppresses them unless permitted
by log_min_messages.

At the moment, this parameter affects only a small set of messages
(about five). We can consider extending it to cover more logical
decoding messages later.

Regards,

--
Fujii Masao

On Wed, Mar 25, 2026 at 12:10 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:

I agree with this. One could use the new log_min_messages feature
introduced in PG19 if wanted. Perhaps, it's a good idea to add this
recommendation to the commit message to help those wanting to enable
these logs.

OK, I will do that later.

I reviewed the v1 patch and it LGTM. Thanks!

Thanks for the review!

Regards,

--
Fujii Masao

Hi,

On Tue, Mar 24, 2026 at 8:15 PM Fujii Masao <masao.fujii@gmail.com> wrote:

On Tue, Mar 24, 2026 at 12:44 AM Fujii Masao <masao.fujii@gmail.com> wrote:

Alternatively, if we want to keep them at LOG by default, we could introduce
a GUC like trace_logical_decoding_messages, similar to
the old trace_recovery_messages, to control their verbosity independently
of log_min_messages.

Just in case where many users still want to see those log messages at LOG level,
I also created a second patch (0002) that introduces a new GUC,
trace_logical_decoding_messages, to control logging of logical
decoding debug messages (e.g., "logical decoding found consistent point").

-1 for another GUC. If needed, we could explore using
log_replication_commands, but I'm okay with your other suggestion on
using the new feature with log_min_messages. Perhaps, we could wait
for some time to hear from others.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

On Wed, Mar 25, 2026 at 12:28 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:

Hi,

On Tue, Mar 24, 2026 at 8:15 PM Fujii Masao <masao.fujii@gmail.com> wrote:

On Tue, Mar 24, 2026 at 12:44 AM Fujii Masao <masao.fujii@gmail.com> wrote:

Alternatively, if we want to keep them at LOG by default, we could introduce
a GUC like trace_logical_decoding_messages, similar to
the old trace_recovery_messages, to control their verbosity independently
of log_min_messages.

Just in case where many users still want to see those log messages at LOG level,
I also created a second patch (0002) that introduces a new GUC,
trace_logical_decoding_messages, to control logging of logical
decoding debug messages (e.g., "logical decoding found consistent point").

-1 for another GUC. If needed, we could explore using
log_replication_commands, but I'm okay with your other suggestion on
using the new feature with log_min_messages.

I'd prefer this approach.

Perhaps, we could wait
for some time to hear from others.

+1.

If there are no further comments in the next few days, and given the limited
time before feature freeze, I'm inclined to at least apply the 0001 patch
(which simply lowers the log level to DEBUG1).

Regards,

--
Fujii Masao

On Wed, Mar 25, 2026 at 2:54 PM Fujii Masao <masao.fujii@gmail.com> wrote:

Perhaps, we could wait
for some time to hear from others.

+1.

If there are no further comments in the next few days, and given the limited
time before feature freeze, I'm inclined to at least apply the 0001 patch
(which simply lowers the log level to DEBUG1).

Since there were no objections for about a week, I've pushed the 0001
patch. Thanks!

If any issues or concerns are raised, let's consider applying the 0002 patch!

Regards,

--
Fujii Masao

On Apr 1, 2026, at 14:48, Fujii Masao <masao.fujii@gmail.com> wrote:

On Wed, Mar 25, 2026 at 2:54 PM Fujii Masao <masao.fujii@gmail.com> wrote:

Perhaps, we could wait
for some time to hear from others.

+1.

If there are no further comments in the next few days, and given the limited
time before feature freeze, I'm inclined to at least apply the 0001 patch
(which simply lowers the log level to DEBUG1).

Since there were no objections for about a week, I've pushed the 0001
patch. Thanks!

If any issues or concerns are raised, let's consider applying the 0002 patch!

Regards,

--
Fujii Masao

TBH, I’m not quite sure what practical benefit this patch set provides.

In 0001, some messages are changed from LOG to DEBUG1. But then 0002 introduces trace_logical_decoding_messages, whose default is DEBUG1, so with the default setting those messages are effectively promoted back to LOG again. That seems to cancel out the behavior change from 0001 by default.

Also, looking at where trace_logical_decoding() is applied in 0002, all the call sites currently pass DEBUG1. So in practice, if a user sets trace_logical_decoding_messages to anything higher than DEBUG1, all of those messages disappear. That makes it feel more like an on/off switch than a mechanism for filtering messages by level.

So at least to me, the overall value of this patch is still not very clear.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/