Subject: Warn when creating or enabling a subscription with max_logical_replication_workers = 0

From: Yugo Nagata <[email-masked]>
Date: Wed, 4 Feb 2026 14:07:31 +0900

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-masked]>
>From 6e59f4bd435b7e34837559c952f6b04475b43b09 Mon Sep 17 00:00:00 2001
From: Yugo Nagata <[email-masked]>
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

---

From: Peter Smith <[email-masked]>
Date: Wed, 4 Feb 2026 17:26:25 +1100

> 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-WORKERS

Kind Regards,
Peter Smith
Fujitsu Australia

---

From: Yugo Nagata <[email-masked]>
Date: Thu, 5 Feb 2026 10:12:39 +0900

On Wed, 4 Feb 2026 17:26:25 +1100

> does the maximum get to be 0 unless the user had explicitly configured

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.

> to function properly, rather than checking what the maximum value is

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

---

From: Peter Smith <[email-masked]>
Date: Thu, 5 Feb 2026 18:46:58 +1100

> 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"));
+	}
 }
 
 /*