public inbox for [email protected]help / color / mirror / Atom feed
Warn when creating or enabling a subscription with max_logical_replication_workers = 0 4+ messages / 2 participants [nested] [flat]
* Warn when creating or enabling a subscription with max_logical_replication_workers = 0 @ 2026-02-04 05:07 Yugo Nagata <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Yugo Nagata @ 2026-02-04 05:07 UTC (permalink / raw) To: pgsql-hackers Hi, I would like to propose emitting a warning when creating or enabling a subscription while max_logical_replication_workers is set to 0. In this case, the CREATE/ALTER SUBSCRIPTION command completes successfully without any warning, making it difficult to notice that logical replication cannot start. Of course, users can confirm whether logical replication is working by checking system views such as pg_stat_replication or pg_stat_subscription. However, emitting warnings explicitly in these cases would make this situation more visible. We have seen user reports where this behavior caused confusion, with users wondering why replication did not start. I've attached a patch to address this. Regards, Yugo Nagata -- Yugo Nagata <[email protected]> Attachments: [text/x-diff] 0001-Warn-when-creating-or-enabling-a-subscription-with-l.patch (1.9K, 2-0001-Warn-when-creating-or-enabling-a-subscription-with-l.patch) download | inline diff: From 6e59f4bd435b7e34837559c952f6b04475b43b09 Mon Sep 17 00:00:00 2001 From: Yugo Nagata <[email protected]> Date: Sun, 1 Feb 2026 23:09:46 +0900 Subject: [PATCH] Warn when creating or enabling a subscription with logical replication disabled If max_logical_replication_workers is zero, logical replication is disabled and will never start, even if a subscription is created or enabled. Previously, these commands completed successfully without any warning, making it difficult to notice that logical replication could not start. Emit warnings in these cases to make this situation more visible. --- src/backend/commands/subscriptioncmds.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/subscriptioncmds.c b/src/backend/commands/subscriptioncmds.c index 0b3c8499b49..55ba4bfb53e 100644 --- a/src/backend/commands/subscriptioncmds.c +++ b/src/backend/commands/subscriptioncmds.c @@ -906,7 +906,14 @@ CreateSubscription(ParseState *pstate, CreateSubscriptionStmt *stmt, * conflict during replication. */ if (opts.enabled || opts.retaindeadtuples) + { + if (max_logical_replication_workers == 0) + ereport(WARNING, + (errmsg("subscription was created, but logical replication is disabled"), + errhint("To initiate replication, set \"max_logical_replication_workers\" to a non zero value."))); + ApplyLauncherWakeupAtCommit(); + } ObjectAddressSet(myself, SubscriptionRelationId, subid); @@ -1694,7 +1701,14 @@ AlterSubscription(ParseState *pstate, AlterSubscriptionStmt *stmt, replaces[Anum_pg_subscription_subenabled - 1] = true; if (opts.enabled) + { + if (max_logical_replication_workers == 0) + ereport(WARNING, + (errmsg("subscription was enabled, but logical replication is disabled"), + errhint("To initiate replication, set \"max_logical_replication_workers\" to a non zero value."))); + ApplyLauncherWakeupAtCommit(); + } update_tuple = true; -- 2.43.0 ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 @ 2026-02-04 06:26 Peter Smith <[email protected]> parent: Yugo Nagata <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Peter Smith @ 2026-02-04 06:26 UTC (permalink / raw) To: Yugo Nagata <[email protected]>; +Cc: pgsql-hackers On Wed, Feb 4, 2026 at 4:07 PM Yugo Nagata <[email protected]> wrote: > > Hi, > > I would like to propose emitting a warning when creating or enabling a > subscription while max_logical_replication_workers is set to 0. In this > case, the CREATE/ALTER SUBSCRIPTION command completes successfully without > any warning, making it difficult to notice that logical replication cannot > start. > > Of course, users can confirm whether logical replication is working by > checking system views such as pg_stat_replication or pg_stat_subscription. > However, emitting warnings explicitly in these cases would make this > situation more visible. We have seen user reports where this behavior > caused confusion, with users wondering why replication did not start. > Hi Nagata-San. AFAIK the default for `max_logical_replication_workers` is 4. So how does the maximum get to be 0 unless the user had explicitly configured it that way? Also subscriptions require multiple workers in order to work properly [1] so why check only 0? Why not check 1 or 2 or 3.... those low numbers are also likely to cause similar problems aren't they? And what about when the `max_logical_replication_workers` is 100, but those 100 are already being used. IOW, would it be more useful to warn when you do not have enough *available* workers for the Subscription to function properly, rather than checking what the maximum value is set to? ====== [1] https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-MAX-LOGICAL-REPLICATION-... Kind Regards, Peter Smith Fujitsu Australia ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 @ 2026-02-05 01:12 Yugo Nagata <[email protected]> parent: Peter Smith <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Yugo Nagata @ 2026-02-05 01:12 UTC (permalink / raw) To: Peter Smith <[email protected]>; +Cc: pgsql-hackers On Wed, 4 Feb 2026 17:26:25 +1100 Peter Smith <[email protected]> wrote: > On Wed, Feb 4, 2026 at 4:07 PM Yugo Nagata <[email protected]> wrote: > > > > Hi, > > > > I would like to propose emitting a warning when creating or enabling a > > subscription while max_logical_replication_workers is set to 0. In this > > case, the CREATE/ALTER SUBSCRIPTION command completes successfully without > > any warning, making it difficult to notice that logical replication cannot > > start. > > > > Of course, users can confirm whether logical replication is working by > > checking system views such as pg_stat_replication or pg_stat_subscription. > > However, emitting warnings explicitly in these cases would make this > > situation more visible. We have seen user reports where this behavior > > caused confusion, with users wondering why replication did not start. > > > > Hi Nagata-San. > > AFAIK the default for `max_logical_replication_workers` is 4. So how > does the maximum get to be 0 unless the user had explicitly configured > it that way? That's correct, but the goal here is simply to make it easier for users to be aware of this condition, since the current behavior provides no indication that replication will not start. > Also subscriptions require multiple workers in order to work properly > [1] so why check only 0? Why not check 1 or 2 or 3.... those low > numbers are also likely to cause similar problems aren't they? > > And what about when the `max_logical_replication_workers` is 100, but > those 100 are already being used. IOW, would it be more useful to warn > when you do not have enough *available* workers for the Subscription > to function properly, rather than checking what the maximum value is > set to? When max_logical_replication_workers is zero, the logical replication launcher will never start. Otherwise, it does start and emits the following warning to the server log when workers cannot be obtained: WARNING: out of logical replication worker slots HINT: You might need to increase "max_logical_replication_workers" Given this, I think it is sufficient to warn only when max_logical_replication_workers is zero. That said, this warning is currently emitted only to the server log and does not appear as a response to CREATE/ALTER SUBSCRIPTION. However, I'm not sure whether emitting a similar warning as part of the CREATE/ALTER SUBSCRIPTION response would add much value. Regards, Yugo Nagata > > ====== > [1] https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-MAX-LOGICAL-REPLICATION-... > > Kind Regards, > Peter Smith > Fujitsu Australia > > -- Yugo Nagata <[email protected]> ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 @ 2026-02-05 07:46 Peter Smith <[email protected]> parent: Yugo Nagata <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Peter Smith @ 2026-02-05 07:46 UTC (permalink / raw) To: Yugo Nagata <[email protected]>; +Cc: pgsql-hackers On Thu, Feb 5, 2026 at 12:12 PM Yugo Nagata <[email protected]> wrote: > > On Wed, 4 Feb 2026 17:26:25 +1100 > Peter Smith <[email protected]> wrote: > > > On Wed, Feb 4, 2026 at 4:07 PM Yugo Nagata <[email protected]> wrote: > > > > > > Hi, > > > > > > I would like to propose emitting a warning when creating or enabling a > > > subscription while max_logical_replication_workers is set to 0. In this > > > case, the CREATE/ALTER SUBSCRIPTION command completes successfully without > > > any warning, making it difficult to notice that logical replication cannot > > > start. > > > > > > Of course, users can confirm whether logical replication is working by > > > checking system views such as pg_stat_replication or pg_stat_subscription. > > > However, emitting warnings explicitly in these cases would make this > > > situation more visible. We have seen user reports where this behavior > > > caused confusion, with users wondering why replication did not start. > > > > > > > Hi Nagata-San. > > > > AFAIK the default for `max_logical_replication_workers` is 4. So how > > does the maximum get to be 0 unless the user had explicitly configured > > it that way? > > That's correct, but the goal here is simply to make it easier for users to > be aware of this condition, since the current behavior provides no > indication that replication will not start. > > > Also subscriptions require multiple workers in order to work properly > > [1] so why check only 0? Why not check 1 or 2 or 3.... those low > > numbers are also likely to cause similar problems aren't they? > > > > And what about when the `max_logical_replication_workers` is 100, but > > those 100 are already being used. IOW, would it be more useful to warn > > when you do not have enough *available* workers for the Subscription > > to function properly, rather than checking what the maximum value is > > set to? > > When max_logical_replication_workers is zero, the logical replication > launcher will never start. Otherwise, it does start and emits the > following warning to the server log when workers cannot be obtained: > > WARNING: out of logical replication worker slots > HINT: You might need to increase "max_logical_replication_workers" > > Given this, I think it is sufficient to warn only when > max_logical_replication_workers is zero. > Hi Nagata-San, Oh right, I mistook that you had run out of logical replication "workers", but in fact, because max_logical_replication_workers = 0 the main "logical replication launcher" process had failed to start, so logical replication was entirely disabled. See code: in backend/replication/logical/launcher.c ApplyLauncherRegister(void) { ... if (max_logical_replication_workers == 0 || IsBinaryUpgrade) return; ~~~ Given this, I felt that instead of testing the GUC, what you really want to know is just whether that "logical replication launcher" is running or not. And that launcher pid is already tested when the Subscription commands send a "kill" to the launcher. e.g. see function ApplyLauncherWakeup. So, here is a diff patch, of what I tried: ------ diff --git a/src/backend/replication/logical/launcher.c b/src/backend/replication/logical/launcher.c index 3ed86480be2..f880380ce4e 100644 --- a/src/backend/replication/logical/launcher.c +++ b/src/backend/replication/logical/launcher.c @@ -1195,6 +1195,13 @@ ApplyLauncherWakeup(void) { if (LogicalRepCtx->launcher_pid != 0) kill(LogicalRepCtx->launcher_pid, SIGUSR1); + else + { + if (max_logical_replication_workers == 0) + ereport(WARNING, + errmsg("Logical replication is currently disabled"), + errhint("\"%s\" is 0.", "max_logical_replication_workers")); + } } ------ AND THE RESULT: ---------- test_sub=# create subscription sub1 connection 'dbname=test_pub' publication pub1; NOTICE: created replication slot "sub1" on publisher WARNING: Logical replication is currently disabled HINT: "max_logical_replication_workers" is 0 CREATE SUBSCRIPTION test_sub=# test_sub=# alter subscription sub1 disable; ALTER SUBSCRIPTION test_sub=# alter subscription sub1 enable; WARNING: Logical replication is currently disabled HINT: "max_logical_replication_workers" is 0 ALTER SUBSCRIPTION test_sub=# ---------- IIUC, that seems to be giving the CREATE/ALTER warnings that you wanted. Thoughts? ====== Kind Regards, Peter Smith. Fujitsu Australia diff --git a/src/backend/replication/logical/launcher.c b/src/backend/replication/logical/launcher.c index 3ed86480be2..f880380ce4e 100644 --- a/src/backend/replication/logical/launcher.c +++ b/src/backend/replication/logical/launcher.c @@ -1195,6 +1195,13 @@ ApplyLauncherWakeup(void) { if (LogicalRepCtx->launcher_pid != 0) kill(LogicalRepCtx->launcher_pid, SIGUSR1); + else + { + if (max_logical_replication_workers == 0) + ereport(WARNING, + errmsg("Logical replication is currently disabled"), + errhint("\"%s\" is 0.", "max_logical_replication_workers")); + } } /* Attachments: [text/plain] PS_warn_no_launcher.txt (590B, 2-PS_warn_no_launcher.txt) download | inline diff: diff --git a/src/backend/replication/logical/launcher.c b/src/backend/replication/logical/launcher.c index 3ed86480be2..f880380ce4e 100644 --- a/src/backend/replication/logical/launcher.c +++ b/src/backend/replication/logical/launcher.c @@ -1195,6 +1195,13 @@ ApplyLauncherWakeup(void) { if (LogicalRepCtx->launcher_pid != 0) kill(LogicalRepCtx->launcher_pid, SIGUSR1); + else + { + if (max_logical_replication_workers == 0) + ereport(WARNING, + errmsg("Logical replication is currently disabled"), + errhint("\"%s\" is 0.", "max_logical_replication_workers")); + } } /* ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-02-05 07:46 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-02-04 05:07 Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Yugo Nagata <[email protected]> 2026-02-04 06:26 ` Peter Smith <[email protected]> 2026-02-05 01:12 ` Yugo Nagata <[email protected]> 2026-02-05 07:46 ` Peter Smith <[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