public inbox for [email protected]
help / color / mirror / Atom feedReduce log level of some logical decoding messages to DEBUG1
10+ messages / 3 participants
[nested] [flat]
* Reduce log level of some logical decoding messages to DEBUG1
@ 2026-03-23 08:23 Fujii Masao <[email protected]>
2026-03-23 13:53 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Bharath Rupireddy <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Fujii Masao @ 2026-03-23 08:23 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
Hi,
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.
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?
This topic came up in [1] and [2], and Amit suggested discussing it separately,
so I started this thread.
Regards,
[1] https://postgr.es/m/CAHGQGwF6zG9Z8ws1yb3hY1VqV-WT7hR0qyXCn2HdbjvZQKufDw@mail.gmail.com
[2] https://postgr.es/m/CAHGQGwED5kJxZ_MdCh=WLa5M7ekXdnzCO1ZCQhQNCEdfaEPwFQ@mail.gmail.com
--
Fujii Masao
Attachments:
[application/octet-stream] v1-0001-Reduce-log-level-of-some-logical-decoding-message.patch (3.3K, 2-v1-0001-Reduce-log-level-of-some-logical-decoding-message.patch)
download | inline diff:
From 33a5bdcfcb932c4b093fdc79fc0408de3e0c2e52 Mon Sep 17 00:00:00 2001
From: Fujii Masao <[email protected]>
Date: Thu, 19 Mar 2026 20:32:43 +0900
Subject: [PATCH v1] Reduce log level of some logical decoding messages from
LOG to DEBUG1
Previously some logical decoding messages (e.g., "logical decoding found
consistent point") were logged at level LOG, even though they provided
low-level, developer-oriented information that DBAs were typically not
interested in.
Since these messages can occur routinely (for example, when keeping calling
pg_logical_slot_get_changes() to obtain the changes from logical decoding),
logging them at LOG can be overly verbose.
This commit reduces their log level to DEBUG1 to avoid unnecessary log noise.
---
src/backend/replication/logical/logical.c | 2 +-
src/backend/replication/logical/snapbuild.c | 6 +++---
src/test/recovery/t/038_save_logical_slots_shutdown.pl | 1 +
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index 603a2b94d05..f20d0c542f3 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -598,7 +598,7 @@ CreateDecodingContext(XLogRecPtr start_lsn,
ctx->reorder->output_rewrites = ctx->options.receive_rewrites;
- ereport(LOG,
+ ereport(DEBUG1,
(errmsg("starting logical decoding for slot \"%s\"",
NameStr(slot->data.name)),
errdetail("Streaming transactions committing after %X/%08X, reading WAL from %X/%08X.",
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index 37f0c6028bd..b4269a3b102 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -1312,7 +1312,7 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
builder->state = SNAPBUILD_CONSISTENT;
builder->next_phase_at = InvalidTransactionId;
- ereport(LOG,
+ ereport(DEBUG1,
errmsg("logical decoding found consistent point at %X/%08X",
LSN_FORMAT_ARGS(lsn)),
errdetail("There are no running transactions."));
@@ -1409,7 +1409,7 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
builder->state = SNAPBUILD_CONSISTENT;
builder->next_phase_at = InvalidTransactionId;
- ereport(LOG,
+ ereport(DEBUG1,
errmsg("logical decoding found consistent point at %X/%08X",
LSN_FORMAT_ARGS(lsn)),
errdetail("There are no old transactions anymore."));
@@ -1915,7 +1915,7 @@ SnapBuildRestore(SnapBuild *builder, XLogRecPtr lsn)
Assert(builder->state == SNAPBUILD_CONSISTENT);
- ereport(LOG,
+ ereport(DEBUG1,
errmsg("logical decoding found consistent point at %X/%08X",
LSN_FORMAT_ARGS(lsn)),
errdetail("Logical decoding will begin using saved snapshot."));
diff --git a/src/test/recovery/t/038_save_logical_slots_shutdown.pl b/src/test/recovery/t/038_save_logical_slots_shutdown.pl
index c0392d50460..05aa78b4bc7 100644
--- a/src/test/recovery/t/038_save_logical_slots_shutdown.pl
+++ b/src/test/recovery/t/038_save_logical_slots_shutdown.pl
@@ -48,6 +48,7 @@ $node_publisher->append_conf(
'postgresql.conf', q{
checkpoint_timeout = 1h
autovacuum = off
+log_min_messages = 'debug1'
});
$node_publisher->start;
--
2.51.2
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Reduce log level of some logical decoding messages to DEBUG1
2026-03-23 08:23 Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
@ 2026-03-23 13:53 ` Bharath Rupireddy <[email protected]>
2026-03-23 15:44 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Bharath Rupireddy @ 2026-03-23 13:53 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
Hi,
On Mon, Mar 23, 2026 at 1:23 AM Fujii Masao <[email protected]> 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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Reduce log level of some logical decoding messages to DEBUG1
2026-03-23 08:23 Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-23 13:53 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Bharath Rupireddy <[email protected]>
@ 2026-03-23 15:44 ` Fujii Masao <[email protected]>
2026-03-25 03:09 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Bharath Rupireddy <[email protected]>
2026-03-25 03:15 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
0 siblings, 2 replies; 10+ messages in thread
From: Fujii Masao @ 2026-03-23 15:44 UTC (permalink / raw)
To: Bharath Rupireddy <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On Mon, Mar 23, 2026 at 10:53 PM Bharath Rupireddy
<[email protected]> wrote:
>
> Hi,
>
> On Mon, Mar 23, 2026 at 1:23 AM Fujii Masao <[email protected]> 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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Reduce log level of some logical decoding messages to DEBUG1
2026-03-23 08:23 Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-23 13:53 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Bharath Rupireddy <[email protected]>
2026-03-23 15:44 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
@ 2026-03-25 03:09 ` Bharath Rupireddy <[email protected]>
2026-03-25 03:16 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
1 sibling, 1 reply; 10+ messages in thread
From: Bharath Rupireddy @ 2026-03-25 03:09 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
Hi,
On Mon, Mar 23, 2026 at 8:44 AM Fujii Masao <[email protected]> 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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Reduce log level of some logical decoding messages to DEBUG1
2026-03-23 08:23 Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-23 13:53 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Bharath Rupireddy <[email protected]>
2026-03-23 15:44 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-25 03:09 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Bharath Rupireddy <[email protected]>
@ 2026-03-25 03:16 ` Fujii Masao <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Fujii Masao @ 2026-03-25 03:16 UTC (permalink / raw)
To: Bharath Rupireddy <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On Wed, Mar 25, 2026 at 12:10 PM Bharath Rupireddy
<[email protected]> 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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Reduce log level of some logical decoding messages to DEBUG1
2026-03-23 08:23 Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-23 13:53 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Bharath Rupireddy <[email protected]>
2026-03-23 15:44 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
@ 2026-03-25 03:15 ` Fujii Masao <[email protected]>
2026-03-25 03:28 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Bharath Rupireddy <[email protected]>
1 sibling, 1 reply; 10+ messages in thread
From: Fujii Masao @ 2026-03-25 03:15 UTC (permalink / raw)
To: Bharath Rupireddy <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On Tue, Mar 24, 2026 at 12:44 AM Fujii Masao <[email protected]> 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
Attachments:
[application/octet-stream] v2-0001-Reduce-log-level-of-some-logical-decoding-message.patch (3.3K, 2-v2-0001-Reduce-log-level-of-some-logical-decoding-message.patch)
download | inline diff:
From 9807b9e4b2e78ae3b5a0dd5e6c28eb1ebbd6756d Mon Sep 17 00:00:00 2001
From: Fujii Masao <[email protected]>
Date: Thu, 19 Mar 2026 20:32:43 +0900
Subject: [PATCH v2 1/2] Reduce log level of some logical decoding messages
from LOG to DEBUG1
Previously some logical decoding messages (e.g., "logical decoding found
consistent point") were logged at level LOG, even though they provided
low-level, developer-oriented information that DBAs were typically not
interested in.
Since these messages can occur routinely (for example, when keeping calling
pg_logical_slot_get_changes() to obtain the changes from logical decoding),
logging them at LOG can be overly verbose.
This commit reduces their log level to DEBUG1 to avoid unnecessary log noise.
---
src/backend/replication/logical/logical.c | 2 +-
src/backend/replication/logical/snapbuild.c | 6 +++---
src/test/recovery/t/038_save_logical_slots_shutdown.pl | 1 +
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index 603a2b94d05..f20d0c542f3 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -598,7 +598,7 @@ CreateDecodingContext(XLogRecPtr start_lsn,
ctx->reorder->output_rewrites = ctx->options.receive_rewrites;
- ereport(LOG,
+ ereport(DEBUG1,
(errmsg("starting logical decoding for slot \"%s\"",
NameStr(slot->data.name)),
errdetail("Streaming transactions committing after %X/%08X, reading WAL from %X/%08X.",
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index 37f0c6028bd..b4269a3b102 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -1312,7 +1312,7 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
builder->state = SNAPBUILD_CONSISTENT;
builder->next_phase_at = InvalidTransactionId;
- ereport(LOG,
+ ereport(DEBUG1,
errmsg("logical decoding found consistent point at %X/%08X",
LSN_FORMAT_ARGS(lsn)),
errdetail("There are no running transactions."));
@@ -1409,7 +1409,7 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
builder->state = SNAPBUILD_CONSISTENT;
builder->next_phase_at = InvalidTransactionId;
- ereport(LOG,
+ ereport(DEBUG1,
errmsg("logical decoding found consistent point at %X/%08X",
LSN_FORMAT_ARGS(lsn)),
errdetail("There are no old transactions anymore."));
@@ -1915,7 +1915,7 @@ SnapBuildRestore(SnapBuild *builder, XLogRecPtr lsn)
Assert(builder->state == SNAPBUILD_CONSISTENT);
- ereport(LOG,
+ ereport(DEBUG1,
errmsg("logical decoding found consistent point at %X/%08X",
LSN_FORMAT_ARGS(lsn)),
errdetail("Logical decoding will begin using saved snapshot."));
diff --git a/src/test/recovery/t/038_save_logical_slots_shutdown.pl b/src/test/recovery/t/038_save_logical_slots_shutdown.pl
index c0392d50460..05aa78b4bc7 100644
--- a/src/test/recovery/t/038_save_logical_slots_shutdown.pl
+++ b/src/test/recovery/t/038_save_logical_slots_shutdown.pl
@@ -48,6 +48,7 @@ $node_publisher->append_conf(
'postgresql.conf', q{
checkpoint_timeout = 1h
autovacuum = off
+log_min_messages = 'debug1'
});
$node_publisher->start;
--
2.51.2
[application/octet-stream] v2-0002-Add-trace_logical_decoding_messages-GUC-to-contro.patch (9.6K, 3-v2-0002-Add-trace_logical_decoding_messages-GUC-to-contro.patch)
download | inline diff:
From 20762f88ad95ea1a3d09352e294993e0ab7d0d19 Mon Sep 17 00:00:00 2001
From: Fujii Masao <[email protected]>
Date: Wed, 25 Mar 2026 11:02:17 +0900
Subject: [PATCH v2 2/2] Add trace_logical_decoding_messages GUC to control
logical decoding logging
This commit introduces a new GUC, trace_logical_decoding_messages, to control
the logging of logical decoding debug messages. This is similar to the former
trace_recovery_messages for recovery debug messages.
This parameter overrides log_min_messages for logical decoding messages only
and is intended for debugging. Valid values are DEBUG5 through DEBUG1, and LOG.
Messages at the configured level or higher are logged as if they were at
LOG level. The default is DEBUG1.
Some logical decoding messages (e.g., "logical decoding found consistent
point") are low-level and were previously considered too verbose for LOG.
However, based on discussion, some users still find it useful to see these
messages at LOG level for debugging. Therefore, with the default setting
(DEBUG1), these messages are logged at LOG level. On the other hand,
setting trace_logical_decoding_messages to LOG can suppress them.
---
doc/src/sgml/config.sgml | 25 ++++++++++++++++++++
src/backend/replication/logical/logical.c | 2 +-
src/backend/replication/logical/logicalctl.c | 24 +++++++++++++++++++
src/backend/replication/logical/snapbuild.c | 8 +++----
src/backend/utils/misc/guc_parameters.dat | 11 +++++++++
src/backend/utils/misc/guc_tables.c | 1 +
src/include/replication/logicalctl.h | 3 +++
7 files changed, 69 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 8cdd826fbd3..b48a80c5508 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -12595,6 +12595,31 @@ dynamic_library_path = '/usr/local/lib/postgresql:$libdir'
</listitem>
</varlistentry>
+ <varlistentry id="guc-trace-logical-decoding-messages" xreflabel="trace_logical_decoding_messages">
+ <term><varname>trace_logical_decoding_messages</varname> (<type>enum</type>)
+ <indexterm>
+ <primary><varname>trace_logical_decoding_messages</varname> configuration parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Enables logging of logical decoding-related debugging output that
+ otherwise would not be logged. This parameter allows the user to
+ override the normal setting of <xref linkend="guc-log-min-messages"/>,
+ but only for specific messages. This is intended for use in debugging
+ logical decoding. Valid values are <literal>DEBUG5</literal>,
+ <literal>DEBUG4</literal>, <literal>DEBUG3</literal>,
+ <literal>DEBUG2</literal>, <literal>DEBUG1</literal>, and
+ <literal>LOG</literal>. The setting values cause logical
+ decoding-related debug messages of that priority or higher to be logged
+ as though they had <literal>LOG</literal> priority; for common settings
+ of <varname>log_min_messages</varname> this results in unconditionally
+ sending them to the server log.
+ The default is <literal>DEBUG1</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="guc-trace-notify" xreflabel="trace_notify">
<term><varname>trace_notify</varname> (<type>boolean</type>)
<indexterm>
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index f20d0c542f3..7d3c0da70f6 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -598,7 +598,7 @@ CreateDecodingContext(XLogRecPtr start_lsn,
ctx->reorder->output_rewrites = ctx->options.receive_rewrites;
- ereport(DEBUG1,
+ ereport(trace_logical_decoding(DEBUG1),
(errmsg("starting logical decoding for slot \"%s\"",
NameStr(slot->data.name)),
errdetail("Streaming transactions committing after %X/%08X, reading WAL from %X/%08X.",
diff --git a/src/backend/replication/logical/logicalctl.c b/src/backend/replication/logical/logicalctl.c
index 4e292951201..d735a63d828 100644
--- a/src/backend/replication/logical/logicalctl.c
+++ b/src/backend/replication/logical/logicalctl.c
@@ -116,6 +116,9 @@ bool XLogLogicalInfo = false;
*/
static bool XLogLogicalInfoUpdatePending = false;
+/* GUC variables */
+int trace_logical_decoding_messages = DEBUG1;
+
static void update_xlog_logical_info(void);
static void abort_logical_decoding_activation(int code, Datum arg);
static void write_logical_decoding_status_update_record(bool status);
@@ -638,3 +641,24 @@ UpdateLogicalDecodingStatusEndOfRecovery(void)
INJECTION_POINT("startup-logical-decoding-status-change-end-of-recovery", NULL);
}
+
+/*
+ * Adjust the level of a logical decoding-related message per
+ * trace_logical_decoding_messages.
+ *
+ * The argument is the default log level of the message, eg, DEBUG2. (This
+ * should only be applied to DEBUGn log messages, otherwise it's a no-op.)
+ * If the level is >= trace_logical_decoding_messages, we return LOG, causing
+ * the message to be logged unconditionally (for most settings of
+ * log_min_messages). Otherwise, we return the argument unchanged.
+ * The message will then be shown based on the setting of log_min_messages.
+ */
+int
+trace_logical_decoding(int trace_level)
+{
+ if (trace_level < LOG &&
+ trace_level >= trace_logical_decoding_messages)
+ return LOG;
+
+ return trace_level;
+}
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..6c878cbcfd0 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -1312,7 +1312,7 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
builder->state = SNAPBUILD_CONSISTENT;
builder->next_phase_at = InvalidTransactionId;
- ereport(DEBUG1,
+ ereport(trace_logical_decoding(DEBUG1),
errmsg("logical decoding found consistent point at %X/%08X",
LSN_FORMAT_ARGS(lsn)),
errdetail("There are no running transactions."));
@@ -1385,7 +1385,7 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
builder->state = SNAPBUILD_FULL_SNAPSHOT;
builder->next_phase_at = running->nextXid;
- ereport(LOG,
+ ereport(trace_logical_decoding(DEBUG1),
errmsg("logical decoding found initial consistent point at %X/%08X",
LSN_FORMAT_ARGS(lsn)),
errdetail("Waiting for transactions (approximately %d) older than %u to end.",
@@ -1409,7 +1409,7 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
builder->state = SNAPBUILD_CONSISTENT;
builder->next_phase_at = InvalidTransactionId;
- ereport(DEBUG1,
+ ereport(trace_logical_decoding(DEBUG1),
errmsg("logical decoding found consistent point at %X/%08X",
LSN_FORMAT_ARGS(lsn)),
errdetail("There are no old transactions anymore."));
@@ -1915,7 +1915,7 @@ SnapBuildRestore(SnapBuild *builder, XLogRecPtr lsn)
Assert(builder->state == SNAPBUILD_CONSISTENT);
- ereport(DEBUG1,
+ ereport(trace_logical_decoding(DEBUG1),
errmsg("logical decoding found consistent point at %X/%08X",
LSN_FORMAT_ARGS(lsn)),
errdetail("Logical decoding will begin using saved snapshot."));
diff --git a/src/backend/utils/misc/guc_parameters.dat b/src/backend/utils/misc/guc_parameters.dat
index 0c9854ad8fc..04cd0d8c3be 100644
--- a/src/backend/utils/misc/guc_parameters.dat
+++ b/src/backend/utils/misc/guc_parameters.dat
@@ -3039,6 +3039,17 @@
ifdef => 'LOCK_DEBUG',
},
+# client_message_level_options allows too many values, really, but
+# it's not worth having a separate options array for this.
+{ name => 'trace_logical_decoding_messages', type => 'enum', context => 'PGC_USERSET', group => 'DEVELOPER_OPTIONS',
+ short_desc => 'Enables logging of logical decoding-related debugging information.',
+ long_desc => 'Each level includes all the levels that follow it. The later the level, the fewer messages are sent.',
+ flags => 'GUC_NOT_IN_SAMPLE',
+ variable => 'trace_logical_decoding_messages',
+ boot_val => 'DEBUG1',
+ options => 'client_message_level_options',
+},
+
{ name => 'trace_lwlocks', type => 'bool', context => 'PGC_SUSET', group => 'DEVELOPER_OPTIONS',
short_desc => 'Emits information about lightweight lock usage.',
flags => 'GUC_NOT_IN_SAMPLE',
diff --git a/src/backend/utils/misc/guc_tables.c b/src/backend/utils/misc/guc_tables.c
index 1e14b7b4af0..8e83021afa3 100644
--- a/src/backend/utils/misc/guc_tables.c
+++ b/src/backend/utils/misc/guc_tables.c
@@ -72,6 +72,7 @@
#include "postmaster/syslogger.h"
#include "postmaster/walsummarizer.h"
#include "postmaster/walwriter.h"
+#include "replication/logicalctl.h"
#include "replication/logicallauncher.h"
#include "replication/slot.h"
#include "replication/slotsync.h"
diff --git a/src/include/replication/logicalctl.h b/src/include/replication/logicalctl.h
index 495554c532c..6b2db5ba273 100644
--- a/src/include/replication/logicalctl.h
+++ b/src/include/replication/logicalctl.h
@@ -14,6 +14,8 @@
#ifndef LOGICALCTL_H
#define LOGICALCTL_H
+extern PGDLLIMPORT int trace_logical_decoding_messages;
+
extern Size LogicalDecodingCtlShmemSize(void);
extern void LogicalDecodingCtlShmemInit(void);
extern void StartupLogicalDecodingStatus(bool last_status);
@@ -28,5 +30,6 @@ extern void RequestDisableLogicalDecoding(void);
extern void DisableLogicalDecodingIfNecessary(void);
extern void DisableLogicalDecoding(void);
extern void UpdateLogicalDecodingStatusEndOfRecovery(void);
+extern int trace_logical_decoding(int trace_level);
#endif
--
2.51.2
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Reduce log level of some logical decoding messages to DEBUG1
2026-03-23 08:23 Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-23 13:53 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Bharath Rupireddy <[email protected]>
2026-03-23 15:44 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-25 03:15 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
@ 2026-03-25 03:28 ` Bharath Rupireddy <[email protected]>
2026-03-25 05:54 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Bharath Rupireddy @ 2026-03-25 03:28 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
Hi,
On Tue, Mar 24, 2026 at 8:15 PM Fujii Masao <[email protected]> wrote:
>
> On Tue, Mar 24, 2026 at 12:44 AM Fujii Masao <[email protected]> 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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Reduce log level of some logical decoding messages to DEBUG1
2026-03-23 08:23 Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-23 13:53 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Bharath Rupireddy <[email protected]>
2026-03-23 15:44 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-25 03:15 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-25 03:28 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Bharath Rupireddy <[email protected]>
@ 2026-03-25 05:54 ` Fujii Masao <[email protected]>
2026-04-01 06:48 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Fujii Masao @ 2026-03-25 05:54 UTC (permalink / raw)
To: Bharath Rupireddy <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On Wed, Mar 25, 2026 at 12:28 PM Bharath Rupireddy
<[email protected]> wrote:
>
> Hi,
>
> On Tue, Mar 24, 2026 at 8:15 PM Fujii Masao <[email protected]> wrote:
> >
> > On Tue, Mar 24, 2026 at 12:44 AM Fujii Masao <[email protected]> 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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Reduce log level of some logical decoding messages to DEBUG1
2026-03-23 08:23 Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-23 13:53 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Bharath Rupireddy <[email protected]>
2026-03-23 15:44 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-25 03:15 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-25 03:28 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Bharath Rupireddy <[email protected]>
2026-03-25 05:54 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
@ 2026-04-01 06:48 ` Fujii Masao <[email protected]>
2026-04-01 07:30 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Chao Li <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Fujii Masao @ 2026-04-01 06:48 UTC (permalink / raw)
To: Bharath Rupireddy <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On Wed, Mar 25, 2026 at 2:54 PM Fujii Masao <[email protected]> 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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Reduce log level of some logical decoding messages to DEBUG1
2026-03-23 08:23 Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-23 13:53 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Bharath Rupireddy <[email protected]>
2026-03-23 15:44 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-25 03:15 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-25 03:28 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Bharath Rupireddy <[email protected]>
2026-03-25 05:54 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-04-01 06:48 ` Re: Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
@ 2026-04-01 07:30 ` Chao Li <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Chao Li @ 2026-04-01 07:30 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: Bharath Rupireddy <[email protected]>; PostgreSQL Hackers <[email protected]>
> On Apr 1, 2026, at 14:48, Fujii Masao <[email protected]> wrote:
>
> On Wed, Mar 25, 2026 at 2:54 PM Fujii Masao <[email protected]> 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/
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2026-04-01 07:30 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-03-23 08:23 Reduce log level of some logical decoding messages to DEBUG1 Fujii Masao <[email protected]>
2026-03-23 13:53 ` Bharath Rupireddy <[email protected]>
2026-03-23 15:44 ` Fujii Masao <[email protected]>
2026-03-25 03:09 ` Bharath Rupireddy <[email protected]>
2026-03-25 03:16 ` Fujii Masao <[email protected]>
2026-03-25 03:15 ` Fujii Masao <[email protected]>
2026-03-25 03:28 ` Bharath Rupireddy <[email protected]>
2026-03-25 05:54 ` Fujii Masao <[email protected]>
2026-04-01 06:48 ` Fujii Masao <[email protected]>
2026-04-01 07:30 ` Chao Li <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox