public inbox for [email protected]help / color / mirror / Atom feed
pgsql: Reduce log level of some logical decoding messages from LOG to D 15+ messages / 5 participants [nested] [flat]
* pgsql: Reduce log level of some logical decoding messages from LOG to D @ 2026-04-01 06:44 Fujii Masao <[email protected]> 2026-04-02 19:56 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Fujii Masao @ 2026-04-01 06:44 UTC (permalink / raw) To: [email protected] 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. This change applies to a small set of messages for now. Additional messages may be adjusted similarly in the future. Even with this change, if these messages from walsender still need to be observed, enabling DEBUG1 logging selectively for walsender (e.g., log_min_messages = 'warning,walsender:debug1') would be helpful to avoid increasing overall log volume. Author: Fujii Masao <[email protected]> Reviewed-by: Bharath Rupireddy <[email protected]> Discussion: https://postgr.es/m/CAHGQGwGTyHgtD9tyN664x6vQ8Q1G53H7ZUCgBU9_X=nLt3f1QA@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/21b018e7eab57b5e4be183133a8c5b8229eccb3d Modified Files -------------- 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(-) ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Reduce log level of some logical decoding messages from LOG to D 2026-04-01 06:44 pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> @ 2026-04-02 19:56 ` Robert Haas <[email protected]> 2026-04-03 00:45 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Robert Haas @ 2026-04-02 19:56 UTC (permalink / raw) To: Fujii Masao <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]> 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. 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. 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. Thoughts? -- Robert Haas EDB: http://www.enterprisedb.com ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Reduce log level of some logical decoding messages from LOG to D 2026-04-01 06:44 pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-02 19:56 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> @ 2026-04-03 00:45 ` Fujii Masao <[email protected]> 2026-04-06 14:55 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Fujii Masao @ 2026-04-03 00:45 UTC (permalink / raw) To: Robert Haas <[email protected]>; +Cc: Fujii Masao <[email protected]>; PostgreSQL Hackers <[email protected]> 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 ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Reduce log level of some logical decoding messages from LOG to D 2026-04-01 06:44 pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-02 19:56 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-03 00:45 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> @ 2026-04-06 14:55 ` Robert Haas <[email protected]> 2026-04-06 15:57 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Robert Haas @ 2026-04-06 14:55 UTC (permalink / raw) To: Fujii Masao <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]> On Thu, Apr 2, 2026 at 8:45 PM Fujii Masao <[email protected]> wrote: > > 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"? No, what I mean is that if someone runs an SQL function from the foreground, they probably don't want that to result in a LOG message, but if background activity results in such a message, the LOG message is probably a good idea. The reasons are: 1. Somebody might run many foreground queries that rely on the logical decoding infrastructure, so logging something every time such a query is executed could produce a lot of log spam. But there shouldn't be so much background logical decoding for this to be an issue. 2. If logical replication is not working, that may be a major issue for the DBA. A problem running pg_logical_slot_get_changes() is likely not as critical (and if it is, they can always lower client_min_messages or log_min_messages for that session only). -- Robert Haas EDB: http://www.enterprisedb.com ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Reduce log level of some logical decoding messages from LOG to D 2026-04-01 06:44 pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-02 19:56 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-03 00:45 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 14:55 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> @ 2026-04-06 15:57 ` Fujii Masao <[email protected]> 2026-04-06 16:15 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Fujii Masao @ 2026-04-06 15:57 UTC (permalink / raw) To: Robert Haas <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]> On Mon, Apr 6, 2026 at 11:55 PM Robert Haas <[email protected]> wrote: > > On Thu, Apr 2, 2026 at 8:45 PM Fujii Masao <[email protected]> wrote: > > > 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"? > > No, what I mean is that if someone runs an SQL function from the > foreground, they probably don't want that to result in a LOG message, > but if background activity results in such a message, the LOG message > is probably a good idea. The reasons are: > > 1. Somebody might run many foreground queries that rely on the logical > decoding infrastructure, so logging something every time such a query > is executed could produce a lot of log spam. But there shouldn't be so > much background logical decoding for this to be an issue. > > 2. If logical replication is not working, that may be a major issue > for the DBA. A problem running pg_logical_slot_get_changes() is likely > not as critical (and if it is, they can always lower > client_min_messages or log_min_messages for that session only). This seems similar to Bharath's suggestion in [1]. You can already do this by setting log_min_messages = 'warning,walsender:debug1'. With that setting, DEBUG1 logical decoding messages from walsender are logged at LOG, while backends follow log_min_messages=warning, so logical decoding SQL functions don't emit those DEBUG1 messages. 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. 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. Regards, [1] https://postgr.es/m/CALj2ACX_SSJYKt5od1C2874yeotTO9JewfRY9B=3DYx2daUAMw@mail.gmail.com -- Fujii Masao ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Reduce log level of some logical decoding messages from LOG to D 2026-04-01 06:44 pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-02 19:56 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-03 00:45 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 14:55 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-06 15:57 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> @ 2026-04-06 16:15 ` Robert Haas <[email protected]> 2026-04-07 03:04 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Robert Haas @ 2026-04-06 16:15 UTC (permalink / raw) To: Fujii Masao <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]> On Mon, Apr 6, 2026 at 11:57 AM Fujii Masao <[email protected]> wrote: > This seems similar to Bharath's suggestion in [1]. Yes, I think it's the same idea. > You can already do this by > setting log_min_messages = 'warning,walsender:debug1'. With that setting, > DEBUG1 logical decoding messages from walsender are logged at LOG, while > backends follow log_min_messages=warning, so logical decoding SQL functions > don't emit those DEBUG1 messages. > > 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. > 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. -- Robert Haas EDB: http://www.enterprisedb.com ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Reduce log level of some logical decoding messages from LOG to D 2026-04-01 06:44 pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-02 19:56 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-03 00:45 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 14:55 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-06 15:57 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 16:15 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> @ 2026-04-07 03:04 ` Fujii Masao <[email protected]> 2026-04-07 03:18 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Fujii Masao @ 2026-04-07 03:04 UTC (permalink / raw) To: Robert Haas <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]> On Tue, Apr 7, 2026 at 1:16 AM Robert Haas <[email protected]> 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 Attachments: [application/octet-stream] v1-0001-Adjust-log-level-of-logical-decoding-messages-by-.patch (4.8K, 2-v1-0001-Adjust-log-level-of-logical-decoding-messages-by-.patch) download | inline diff: From fbcad31a5d187cb044b46e1b00b24b69adf6e5e5 Mon Sep 17 00:00:00 2001 From: Fujii Masao <[email protected]> Date: Tue, 7 Apr 2026 10:11:22 +0900 Subject: [PATCH v1] Adjust log level of logical decoding messages by context Commit 21b018e7eab lowered some logical decoding messages from LOG to DEBUG1. However, per discussion on pgsql-hackers, messages from background activity (walsender or slotsync worker) should remain at LOG, as they are less frequent and more likely to indicate issues that DBAs should notice. For foreground SQL functions (e.g., pg_logical_slot_peek_binary_changes()), keep these messages at DEBUG1 to avoid excessive log noise. They can still be enabled by lowering client_min_messages or log_min_messages for the session. This commit updates logical decoding to log these messages at LOG for background activity and at DEBUG1 for foreground execution. --- src/backend/replication/logical/logical.c | 2 +- src/backend/replication/logical/snapbuild.c | 6 +++--- src/include/replication/logical.h | 18 ++++++++++++++++++ .../t/038_save_logical_slots_shutdown.pl | 1 - 4 files changed, 22 insertions(+), 5 deletions(-) diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c index f20d0c542f3..5c92fba2f53 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(LogicalDecodingLogLevel(), (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 b4269a3b102..192b1560369 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(LogicalDecodingLogLevel(), 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(DEBUG1, + ereport(LogicalDecodingLogLevel(), 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(LogicalDecodingLogLevel(), 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/include/replication/logical.h b/src/include/replication/logical.h index bc9d4ece672..abf64bdc9d4 100644 --- a/src/include/replication/logical.h +++ b/src/include/replication/logical.h @@ -153,4 +153,22 @@ extern XLogRecPtr LogicalReplicationSlotCheckPendingWal(XLogRecPtr end_of_wal, extern XLogRecPtr LogicalSlotAdvanceAndCheckSnapState(XLogRecPtr moveto, bool *found_consistent_snapshot); + +/* + * This macro determines the log level for messages about starting logical + * decoding and finding a consistent point. + * + * When logical decoding is triggered by a foreground SQL function (e.g., + * pg_logical_slot_peek_binary_changes()), these messages are logged at DEBUG1 + * to avoid excessive log noise. This is acceptable since such issues are + * typically less critical, and the messages can still be enabled by lowering + * client_min_messages or log_min_messages for the session. + * + * When the messages originate from background activity (walsender or + * slotsync worker), they are logged at LOG, as these events are less frequent + * and more likely to indicate issues that DBAs should notice by default. + */ +#define LogicalDecodingLogLevel() \ + ((AmWalSenderProcess() || AmLogicalSlotSyncWorkerProcess()) ? LOG : DEBUG1) + #endif 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 05aa78b4bc7..c0392d50460 100644 --- a/src/test/recovery/t/038_save_logical_slots_shutdown.pl +++ b/src/test/recovery/t/038_save_logical_slots_shutdown.pl @@ -48,7 +48,6 @@ $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] 15+ messages in thread
* Re: pgsql: Reduce log level of some logical decoding messages from LOG to D 2026-04-01 06:44 pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-02 19:56 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-03 00:45 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 14:55 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-06 15:57 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 16:15 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-07 03:04 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> @ 2026-04-07 03:18 ` Amit Kapila <[email protected]> 2026-04-07 03:32 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> 2026-04-07 03:51 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 0 siblings, 2 replies; 15+ messages in thread From: Amit Kapila @ 2026-04-07 03:18 UTC (permalink / raw) To: Fujii Masao <[email protected]>; +Cc: Robert Haas <[email protected]>; PostgreSQL Hackers <[email protected]> On Tue, Apr 7, 2026 at 8:34 AM Fujii Masao <[email protected]> wrote: > > On Tue, Apr 7, 2026 at 1:16 AM Robert Haas <[email protected]> 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. > How about adding repack_worker to that check as well? See 28d534e2ae. > > > > 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. > Yeah, we need to fix that issue. With Regards, Amit Kapila. ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Reduce log level of some logical decoding messages from LOG to D 2026-04-01 06:44 pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-02 19:56 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-03 00:45 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 14:55 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-06 15:57 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 16:15 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-07 03:04 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-07 03:18 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> @ 2026-04-07 03:32 ` Amit Kapila <[email protected]> 2026-04-07 03:54 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 1 sibling, 1 reply; 15+ messages in thread From: Amit Kapila @ 2026-04-07 03:32 UTC (permalink / raw) To: Fujii Masao <[email protected]>; +Cc: Robert Haas <[email protected]>; PostgreSQL Hackers <[email protected]> On Tue, Apr 7, 2026 at 8:48 AM Amit Kapila <[email protected]> wrote: > > On Tue, Apr 7, 2026 at 8:34 AM Fujii Masao <[email protected]> wrote: > > > > On Tue, Apr 7, 2026 at 1:16 AM Robert Haas <[email protected]> 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. > > > > How about adding repack_worker to that check as well? See 28d534e2ae. > The other possibility is to use AmRegularBackendProcess() to decide the log_level in this case. -- With Regards, Amit Kapila. ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Reduce log level of some logical decoding messages from LOG to D 2026-04-01 06:44 pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-02 19:56 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-03 00:45 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 14:55 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-06 15:57 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 16:15 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-07 03:04 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-07 03:18 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> 2026-04-07 03:32 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> @ 2026-04-07 03:54 ` Fujii Masao <[email protected]> 2026-04-07 06:08 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Fujii Masao @ 2026-04-07 03:54 UTC (permalink / raw) To: Amit Kapila <[email protected]>; +Cc: Robert Haas <[email protected]>; PostgreSQL Hackers <[email protected]> On Tue, Apr 7, 2026 at 12:33 PM Amit Kapila <[email protected]> wrote: > The other possibility is to use AmRegularBackendProcess() to decide > the log_level in this case. Yes, that makes sense. (I replied the same idea before seeing this message, sorry for the duplication.) Regards, -- Fujii Masao ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Reduce log level of some logical decoding messages from LOG to D 2026-04-01 06:44 pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-02 19:56 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-03 00:45 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 14:55 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-06 15:57 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 16:15 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-07 03:04 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-07 03:18 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> 2026-04-07 03:32 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> 2026-04-07 03:54 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> @ 2026-04-07 06:08 ` Fujii Masao <[email protected]> 2026-04-10 09:54 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Fujii Masao @ 2026-04-07 06:08 UTC (permalink / raw) To: Amit Kapila <[email protected]>; +Cc: Robert Haas <[email protected]>; PostgreSQL Hackers <[email protected]> On Tue, Apr 7, 2026 at 12:54 PM Fujii Masao <[email protected]> wrote: > > On Tue, Apr 7, 2026 at 12:33 PM Amit Kapila <[email protected]> wrote: > > The other possibility is to use AmRegularBackendProcess() to decide > > the log_level in this case. > > Yes, that makes sense. I've updated the patch to use AmRegularBackendProcess(). Patch attached. Regards, -- Fujii Masao Attachments: [application/octet-stream] v2-0001-Adjust-log-level-of-logical-decoding-messages-by-.patch (4.9K, 2-v2-0001-Adjust-log-level-of-logical-decoding-messages-by-.patch) download | inline diff: From 9e0b40be4871cba8f3cdf1bd4d7ac520d880d59f Mon Sep 17 00:00:00 2001 From: Fujii Masao <[email protected]> Date: Tue, 7 Apr 2026 14:45:08 +0900 Subject: [PATCH v2] Adjust log level of logical decoding messages by context Commit 21b018e7eab lowered some logical decoding messages from LOG to DEBUG1. However, per discussion on pgsql-hackers, messages from background activity (e.g., walsender or slotsync worker) should remain at LOG, as they are less frequent and more likely to indicate issues that DBAs should notice. For foreground SQL functions (e.g., pg_logical_slot_peek_binary_changes()), keep these messages at DEBUG1 to avoid excessive log noise. They can still be enabled by lowering client_min_messages or log_min_messages for the session. This commit updates logical decoding to log these messages at LOG for background activity and at DEBUG1 for foreground execution. --- src/backend/replication/logical/logical.c | 2 +- src/backend/replication/logical/snapbuild.c | 6 +++--- src/include/replication/logical.h | 21 +++++++++++++++++++ .../t/038_save_logical_slots_shutdown.pl | 1 - 4 files changed, 25 insertions(+), 5 deletions(-) diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c index f20d0c542f3..5c92fba2f53 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(LogicalDecodingLogLevel(), (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 b4269a3b102..192b1560369 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(LogicalDecodingLogLevel(), 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(DEBUG1, + ereport(LogicalDecodingLogLevel(), 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(LogicalDecodingLogLevel(), 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/include/replication/logical.h b/src/include/replication/logical.h index bc9d4ece672..4e6cf3896f6 100644 --- a/src/include/replication/logical.h +++ b/src/include/replication/logical.h @@ -153,4 +153,25 @@ extern XLogRecPtr LogicalReplicationSlotCheckPendingWal(XLogRecPtr end_of_wal, extern XLogRecPtr LogicalSlotAdvanceAndCheckSnapState(XLogRecPtr moveto, bool *found_consistent_snapshot); + +/* + * This macro determines the log level for messages about starting logical + * decoding and finding a consistent point. + * + * When logical decoding is triggered by a foreground SQL function (e.g., + * pg_logical_slot_peek_binary_changes()), these messages are logged at DEBUG1 + * to avoid excessive log noise. This is acceptable since such issues are + * typically less critical, and the messages can still be enabled by lowering + * client_min_messages or log_min_messages for the session. + * + * When the messages originate from background activity (e.g., walsender or + * slotsync worker), they are logged at LOG, as these events are less frequent + * and more likely to indicate issues that DBAs should notice by default. + * + * Note that SQL functions executed by the logical walsender are treated as + * background activity. + */ +#define LogicalDecodingLogLevel() \ + (AmRegularBackendProcess() ? DEBUG1 : LOG) + #endif 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 05aa78b4bc7..c0392d50460 100644 --- a/src/test/recovery/t/038_save_logical_slots_shutdown.pl +++ b/src/test/recovery/t/038_save_logical_slots_shutdown.pl @@ -48,7 +48,6 @@ $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] 15+ messages in thread
* Re: pgsql: Reduce log level of some logical decoding messages from LOG to D 2026-04-01 06:44 pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-02 19:56 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-03 00:45 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 14:55 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-06 15:57 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 16:15 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-07 03:04 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-07 03:18 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> 2026-04-07 03:32 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> 2026-04-07 03:54 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-07 06:08 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> @ 2026-04-10 09:54 ` Amit Kapila <[email protected]> 2026-04-10 14:01 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Amit Kapila @ 2026-04-10 09:54 UTC (permalink / raw) To: Fujii Masao <[email protected]>; +Cc: Robert Haas <[email protected]>; PostgreSQL Hackers <[email protected]> On Tue, Apr 7, 2026 at 11:39 AM Fujii Masao <[email protected]> wrote: > > On Tue, Apr 7, 2026 at 12:54 PM Fujii Masao <[email protected]> wrote: > > > > On Tue, Apr 7, 2026 at 12:33 PM Amit Kapila <[email protected]> wrote: > > > The other possibility is to use AmRegularBackendProcess() to decide > > > the log_level in this case. > > > > Yes, that makes sense. > > I've updated the patch to use AmRegularBackendProcess(). Patch attached. > LGTM. -- With Regards, Amit Kapila. ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Reduce log level of some logical decoding messages from LOG to D 2026-04-01 06:44 pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-02 19:56 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-03 00:45 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 14:55 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-06 15:57 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 16:15 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-07 03:04 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-07 03:18 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> 2026-04-07 03:32 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> 2026-04-07 03:54 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-07 06:08 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-10 09:54 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> @ 2026-04-10 14:01 ` Fujii Masao <[email protected]> 2026-04-12 17:55 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Tom Lane <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Fujii Masao @ 2026-04-10 14:01 UTC (permalink / raw) To: Amit Kapila <[email protected]>; +Cc: Robert Haas <[email protected]>; PostgreSQL Hackers <[email protected]> On Fri, Apr 10, 2026 at 6:55 PM Amit Kapila <[email protected]> wrote: > LGTM. Thanks for the review! I've pushed the patch. Regards, -- Fujii Masao ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Reduce log level of some logical decoding messages from LOG to D 2026-04-01 06:44 pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-02 19:56 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-03 00:45 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 14:55 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-06 15:57 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 16:15 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-07 03:04 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-07 03:18 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> 2026-04-07 03:32 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> 2026-04-07 03:54 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-07 06:08 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-10 09:54 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> 2026-04-10 14:01 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> @ 2026-04-12 17:55 ` Tom Lane <[email protected]> 0 siblings, 0 replies; 15+ messages in thread From: Tom Lane @ 2026-04-12 17:55 UTC (permalink / raw) To: Fujii Masao <[email protected]>; +Cc: Amit Kapila <[email protected]>; Robert Haas <[email protected]>; PostgreSQL Hackers <[email protected]> Fujii Masao <[email protected]> writes: > Thanks for the review! I've pushed the patch. de74d1e9a has had a surprising consequence. Coverity has started to whine like this about each use of ereport(LogicalDecodingLogLevel(): >>> CID 1691470: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "((MyBackendType == B_BACKEND) ? 14 : 15) >= 21" is always false regardless of the values of its operands. This occurs as the logical second operand of "&&". 1975 ereport(LogicalDecodingLogLevel(), 1976 errmsg("logical decoding found consistent point at %X/%08X", 1977 LSN_FORMAT_ARGS(lsn)), 1978 errdetail("Logical decoding will begin using saved snapshot.")); It's right of course: neither log level is >= ERROR. I don't see why that would constitute a bug, so this is just useless nannyism from Coverity. We could dismiss these complaints as false positives, but the prospect of having to do that repeatedly in future isn't attractive. I wonder if anyone sees a way to rewrite to dodge this complaint. The only thing I can think of is to turn LogicalDecodingLogLevel() into an out-of-line function, which I think would silence it ... but I might be wrong, and anyway that's not a very attractive solution either. Anybody have a better idea? regards, tom lane ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Reduce log level of some logical decoding messages from LOG to D 2026-04-01 06:44 pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-02 19:56 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-03 00:45 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 14:55 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-06 15:57 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-06 16:15 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Robert Haas <[email protected]> 2026-04-07 03:04 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-07 03:18 ` Re: pgsql: Reduce log level of some logical decoding messages from LOG to D Amit Kapila <[email protected]> @ 2026-04-07 03:51 ` Fujii Masao <[email protected]> 1 sibling, 0 replies; 15+ messages in thread From: Fujii Masao @ 2026-04-07 03:51 UTC (permalink / raw) To: Amit Kapila <[email protected]>; +Cc: Robert Haas <[email protected]>; PostgreSQL Hackers <[email protected]> On Tue, Apr 7, 2026 at 12:18 PM Amit Kapila <[email protected]> wrote: > > On Tue, Apr 7, 2026 at 8:34 AM Fujii Masao <[email protected]> wrote: > > > > On Tue, Apr 7, 2026 at 1:16 AM Robert Haas <[email protected]> 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. > > > > How about adding repack_worker to that check as well? See 28d534e2ae. Thanks for the info! It may be better to use DEBUG1 when AmRegularBackendProcess() is true and LOG otherwise, rather than checking AmWalSenderProcess() or AmLogicalSlotSyncWorkerProcess(). This would also cover any future background processes that use logical decoding. Regards, -- Fujii Masao ^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2026-04-12 17:55 UTC | newest] Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-04-01 06:44 pgsql: Reduce log level of some logical decoding messages from LOG to D Fujii Masao <[email protected]> 2026-04-02 19:56 ` Robert Haas <[email protected]> 2026-04-03 00:45 ` Fujii Masao <[email protected]> 2026-04-06 14:55 ` Robert Haas <[email protected]> 2026-04-06 15:57 ` Fujii Masao <[email protected]> 2026-04-06 16:15 ` Robert Haas <[email protected]> 2026-04-07 03:04 ` Fujii Masao <[email protected]> 2026-04-07 03:18 ` Amit Kapila <[email protected]> 2026-04-07 03:32 ` Amit Kapila <[email protected]> 2026-04-07 03:54 ` Fujii Masao <[email protected]> 2026-04-07 06:08 ` Fujii Masao <[email protected]> 2026-04-10 09:54 ` Amit Kapila <[email protected]> 2026-04-10 14:01 ` Fujii Masao <[email protected]> 2026-04-12 17:55 ` Tom Lane <[email protected]> 2026-04-07 03:51 ` Fujii Masao <[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