Warn when creating or enabling a subscription with max_logical_replication_workers = 0

On Wed, Feb 4, 2026 at 4:07 PM Yugo Nagata <nagata@sraoss.co.jp> 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]: https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-MAX-LOGICAL-REPLICATION-WORKERS
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

On Wed, 4 Feb 2026 17:26:25 +1100
Peter Smith <smithpb2250@gmail.com> wrote:

On Wed, Feb 4, 2026 at 4:07 PM Yugo Nagata <nagata@sraoss.co.jp> 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-WORKERS

Kind Regards,
Peter Smith
Fujitsu Australia

--
Yugo Nagata <nagata@sraoss.co.jp>

On Thu, Feb 5, 2026 at 6:42 AM Yugo Nagata <nagata@sraoss.co.jp> wrote:

On Wed, 4 Feb 2026 17:26:25 +1100
Peter Smith <smithpb2250@gmail.com> wrote:

On Wed, Feb 4, 2026 at 4:07 PM Yugo Nagata <nagata@sraoss.co.jp> 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.

Wouldn't it make sense to emit a WARNING if there are no worker left
to be launched for the SUBSCRIPTION?

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.

Yes, I think it would make more sense to emit WARNING during
CREATE/ALTER SUBSCRIPTION command as well.

--
Regards,
Dilip Kumar
Google

On Thu, Feb 5, 2026 at 12:12 PM Yugo Nagata <nagata@sraoss.co.jp> wrote:

On Wed, 4 Feb 2026 17:26:25 +1100
Peter Smith <smithpb2250@gmail.com> wrote:

On Wed, Feb 4, 2026 at 4:07 PM Yugo Nagata <nagata@sraoss.co.jp> 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

On Thursday, February 5, 2026 3:47 PM Peter Smith <smithpb2250@gmail.com> wrote:

On Thu, Feb 5, 2026 at 12:12 PM Yugo Nagata <nagata@sraoss.co.jp> wrote:

On Wed, 4 Feb 2026 17:26:25 +1100
Peter Smith <smithpb2250@gmail.com> wrote:

On Wed, Feb 4, 2026 at 4:07 PM Yugo Nagata <nagata@sraoss.co.jp>

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

Thoughts?

I think this is not the right place to check this issue. The launcher might fail
for some reasons and restart soon (pid will be set to 0), in which case this
warning wouldn't be appropriate.

Besides, I also think it would make more sense to issue a warning if the
subscription has no remaining workers to start instead of raising a
warning for 0 setting (the latter seems rare).

Best Regards,
Hou zj

On Thu, Feb 5, 2026 at 7:12 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:

On Thursday, February 5, 2026 3:47 PM Peter Smith <smithpb2250@gmail.com> wrote:

On Thu, Feb 5, 2026 at 12:12 PM Yugo Nagata <nagata@sraoss.co.jp> wrote:

On Wed, 4 Feb 2026 17:26:25 +1100
Peter Smith <smithpb2250@gmail.com> wrote:

...

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

Thoughts?

I think this is not the right place to check this issue. The launcher might fail
for some reasons and restart soon (pid will be set to 0), in which case this
warning wouldn't be appropriate.

AFAIK, that's not possible. My warning is guarded by checking
max_logical_replication_workers == 0. And in that case, the launcher
cannot "fail" because it was never registered/started in the first
place.

Besides, I also think it would make more sense to issue a warning if the
subscription has no remaining workers to start instead of raising a
warning for 0 setting (the latter seems rare).

It might be rare, but by my understanding, the original post described
this specific scenario, whereby the user had previously deliberately
configured `max_logical_replication_workers` to 0. Then, some time
later, when they attempted CREATE/ALTER SUBSCRIPTION, nothing
happened, and there was only silence. If they'd forgotten about their
`max_logical_replication_workers` setting, then it could be confusing
why nothing was happening.

OTOH, when max_logical_replication_workers > 0, then the logical
replication launcher would be running, and in that case, there are
already plenty of warning logs about not enough worker resources.

e.g. when max_logical_replication_workers = 1

----------
test_sub=# create subscription sub1 connection 'dbname=test_pub'
publication pub1;
NOTICE: created replication slot "sub1" on publisher
CREATE SUBSCRIPTION
test_sub=# 2026-02-06 08:50:35.306 AEDT [629942] LOG: logical
replication apply worker for subscription "sub1" has started
2026-02-06 08:50:35.348 AEDT [629942] WARNING: out of logical
replication worker slots
2026-02-06 08:50:35.348 AEDT [629942] HINT: You might need to
increase "max_logical_replication_workers".
2026-02-06 08:50:40.356 AEDT [629942] WARNING: out of logical
replication worker slots
2026-02-06 08:50:40.356 AEDT [629942] HINT: You might need to
increase "max_logical_replication_workers".
2026-02-06 08:50:45.365 AEDT [629942] WARNING: out of logical
replication worker slots
2026-02-06 08:50:45.365 AEDT [629942] HINT: You might need to
increase "max_logical_replication_workers".
2026-02-06 08:50:50.426 AEDT [629942] WARNING: out of logical
replication worker slots
2026-02-06 08:50:50.426 AEDT [629942] HINT: You might need to
increase "max_logical_replication_workers".
2026-02-06 08:50:55.531 AEDT [629942] WARNING: out of logical
replication worker slots
2026-02-06 08:50:55.531 AEDT [629942] HINT: You might need to
increase "max_logical_replication_workers".
...
----------

======
Kind Regards,
Peter Smith.
Fujitsu Australia

On Fri, 6 Feb 2026 09:58:02 +1100
Peter Smith <smithpb2250@gmail.com> wrote:

On Thu, Feb 5, 2026 at 7:12 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:

On Thursday, February 5, 2026 3:47 PM Peter Smith <smithpb2250@gmail.com> wrote:

On Thu, Feb 5, 2026 at 12:12 PM Yugo Nagata <nagata@sraoss.co.jp> wrote:

On Wed, 4 Feb 2026 17:26:25 +1100
Peter Smith <smithpb2250@gmail.com> wrote:

...

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

Thoughts?

I think this is not the right place to check this issue. The launcher might fail
for some reasons and restart soon (pid will be set to 0), in which case this
warning wouldn't be appropriate.

AFAIK, that's not possible. My warning is guarded by checking
max_logical_replication_workers == 0. And in that case, the launcher
cannot "fail" because it was never registered/started in the first
place.

I also initially considered emitting the warning in
ApplyLauncherWakeup() after checking　max_logical_replication_workers == 0.
However, I think checking pid == 0 is sufficient.

Even when max_logical_replication_workers is non-zero and the launcher is
normally running, it could still be killed by user action or by the
OS, although such cases should be rare. In that situation, emitting the
same warning would not be appropriate.

I placed the logic in subscriptioncmds.c so that the warning message can
better reflect the actual situation, while keeping consistency with
existing messages such as "subscription was created, but is not
connected".

Besides, I also think it would make more sense to issue a warning if the
subscription has no remaining workers to start instead of raising a
warning for 0 setting (the latter seems rare).

It might be rare, but by my understanding, the original post described
this specific scenario, whereby the user had previously deliberately
configured `max_logical_replication_workers` to 0. Then, some time
later, when they attempted CREATE/ALTER SUBSCRIPTION, nothing
happened, and there was only silence. If they'd forgotten about their
`max_logical_replication_workers` setting, then it could be confusing
why nothing was happening.

OTOH, when max_logical_replication_workers > 0, then the logical
replication launcher would be running, and in that case, there are
already plenty of warning logs about not enough worker resources.

Yes. In this case, warnings are emitted to the server log, but they do not
appear as a response to CREATE/ALTER SUBSCRIPTION. There is an option to
also emit such warnings during the CREATE/ALTER SUBSCRIPTION command, so
I will update the patch accordingly.

Nevertheless, this seems to be a different situation from the case where
logical replication is disabled entirely, so I think the warning messages
should be handled separately.

Regards,
Yugo Nagata

--
Yugo Nagata <nagata@sraoss.co.jp>

On Fri, Feb 6, 2026 at 3:37 PM Yugo Nagata <nagata@sraoss.co.jp> wrote:

On Fri, 6 Feb 2026 09:58:02 +1100
Peter Smith <smithpb2250@gmail.com> wrote:

On Thu, Feb 5, 2026 at 7:12 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:

On Thursday, February 5, 2026 3:47 PM Peter Smith <smithpb2250@gmail.com> wrote:

On Thu, Feb 5, 2026 at 12:12 PM Yugo Nagata <nagata@sraoss.co.jp> wrote:

On Wed, 4 Feb 2026 17:26:25 +1100
Peter Smith <smithpb2250@gmail.com> wrote:

...

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

Thoughts?

I think this is not the right place to check this issue. The launcher might fail
for some reasons and restart soon (pid will be set to 0), in which case this
warning wouldn't be appropriate.

AFAIK, that's not possible. My warning is guarded by checking
max_logical_replication_workers == 0. And in that case, the launcher
cannot "fail" because it was never registered/started in the first
place.

I also initially considered emitting the warning in
ApplyLauncherWakeup() after checking　max_logical_replication_workers == 0.
However, I think checking pid == 0 is sufficient.

Even when max_logical_replication_workers is non-zero and the launcher is
normally running, it could still be killed by user action or by the
OS, although such cases should be rare. In that situation, emitting the
same warning would not be appropriate.

Sorry, I did not understand the previous paragraph. If "when
max_logical_replication_workers is non-zero" then the warning cannot
be emitted inappropriately because that warning is guarded by "if
(max_logical_replication_workers == 0)" (??).

I placed the logic in subscriptioncmds.c so that the warning message can
better reflect the actual situation, while keeping consistency with
existing messages such as "subscription was created, but is not
connected".

In hindsgght your original patch is very similar to what I posted. I
agree, your messages are better because they are more specific. But
there are multiple calls to ApplyLauncherWakeup() -- not just those 2
that you handled - so I was just unsure if there are some remaining
holes.

Besides, I also think it would make more sense to issue a warning if the
subscription has no remaining workers to start instead of raising a
warning for 0 setting (the latter seems rare).

It might be rare, but by my understanding, the original post described
this specific scenario, whereby the user had previously deliberately
configured `max_logical_replication_workers` to 0. Then, some time
later, when they attempted CREATE/ALTER SUBSCRIPTION, nothing
happened, and there was only silence. If they'd forgotten about their
`max_logical_replication_workers` setting, then it could be confusing
why nothing was happening.

OTOH, when max_logical_replication_workers > 0, then the logical
replication launcher would be running, and in that case, there are
already plenty of warning logs about not enough worker resources.

Yes. In this case, warnings are emitted to the server log, but they do not
appear as a response to CREATE/ALTER SUBSCRIPTION. There is an option to
also emit such warnings during the CREATE/ALTER SUBSCRIPTION command, so
I will update the patch accordingly.

Nevertheless, this seems to be a different situation from the case where
logical replication is disabled entirely, so I think the warning messages
should be handled separately.

+1. I also think that running out of worker resources is a different
scenario from the entire logical replication being disabled, so it
should be handled separately

======
Kind Regards,
Peter Smith.
Fujitsu Australia

On Fri, 6 Feb 2026 18:28:06 +1100
Peter Smith <smithpb2250@gmail.com> wrote:

On Fri, Feb 6, 2026 at 3:37 PM Yugo Nagata <nagata@sraoss.co.jp> wrote:

On Fri, 6 Feb 2026 09:58:02 +1100
Peter Smith <smithpb2250@gmail.com> wrote:

On Thu, Feb 5, 2026 at 7:12 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:

On Thursday, February 5, 2026 3:47 PM Peter Smith <smithpb2250@gmail.com> wrote:

On Thu, Feb 5, 2026 at 12:12 PM Yugo Nagata <nagata@sraoss.co.jp> wrote:

On Wed, 4 Feb 2026 17:26:25 +1100
Peter Smith <smithpb2250@gmail.com> wrote:

...

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

Thoughts?

I think this is not the right place to check this issue. The launcher might fail
for some reasons and restart soon (pid will be set to 0), in which case this
warning wouldn't be appropriate.

AFAIK, that's not possible. My warning is guarded by checking
max_logical_replication_workers == 0. And in that case, the launcher
cannot "fail" because it was never registered/started in the first
place.

I also initially considered emitting the warning in
ApplyLauncherWakeup() after checking　max_logical_replication_workers == 0.
However, I think checking pid == 0 is sufficient.

Even when max_logical_replication_workers is non-zero and the launcher is
normally running, it could still be killed by user action or by the
OS, although such cases should be rare. In that situation, emitting the
same warning would not be appropriate.

Sorry, I did not understand the previous paragraph. If "when
max_logical_replication_workers is non-zero" then the warning cannot
be emitted inappropriately because that warning is guarded by "if
(max_logical_replication_workers == 0)" (??).

You're right, I misunderstood that part. Sorry about that.

I placed the logic in subscriptioncmds.c so that the warning message can
better reflect the actual situation, while keeping consistency with
existing messages such as "subscription was created, but is not
connected".

In hindsgght your original patch is very similar to what I posted. I
agree, your messages are better because they are more specific. But
there are multiple calls to ApplyLauncherWakeup() -- not just those 2
that you handled - so I was just unsure if there are some remaining
holes.

I see your point.

There are other places where ApplyLauncherWakeupAtCommit() is called,
for example via AlterSubscription() when retain_dead_tuples is set or
when the owner is changed. However, these cases are not affected when
max_logical_replication_workers = 0 unless the subscription is enabled.

For now, I’ll keep the current approach.

Besides, I also think it would make more sense to issue a warning if the
subscription has no remaining workers to start instead of raising a
warning for 0 setting (the latter seems rare).

It might be rare, but by my understanding, the original post described
this specific scenario, whereby the user had previously deliberately
configured `max_logical_replication_workers` to 0. Then, some time
later, when they attempted CREATE/ALTER SUBSCRIPTION, nothing
happened, and there was only silence. If they'd forgotten about their
`max_logical_replication_workers` setting, then it could be confusing
why nothing was happening.

OTOH, when max_logical_replication_workers > 0, then the logical
replication launcher would be running, and in that case, there are
already plenty of warning logs about not enough worker resources.

Yes. In this case, warnings are emitted to the server log, but they do not
appear as a response to CREATE/ALTER SUBSCRIPTION. There is an option to
also emit such warnings during the CREATE/ALTER SUBSCRIPTION command, so
I will update the patch accordingly.

Nevertheless, this seems to be a different situation from the case where
logical replication is disabled entirely, so I think the warning messages
should be handled separately.

+1. I also think that running out of worker resources is a different
scenario from the entire logical replication being disabled, so it
should be handled separately

I've investigated whether we can emit a warning during CREATE/ALTER SUBSCRIPTION
when there are no available worker slots to start the subscription.

One issue is that, in the current implementation, this condition is only checked
when the launcher actually forks a worker. There is no infrastructure to perform
this check in advance from a backend process.

Adding such infrastructure would likely require acquiring an LWLock (at least in
shared mode) to inspect the current worker state. Moreover, even if we implement
such a mechanism, the situation may change between the time of the check and the
actual worker startup.

Given these limitations, I'm wondering whether introducing this kind of warning
is worthwhile.

Regards,
Yugo Nagata

--
Yugo Nagata <nagata@sraoss.co.jp>