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

On Thursday, February 5, 2026 3:47 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> On Thu, Feb 5, 2026 at 12:12 PM Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> wrote:
> >
> > On Wed, 4 Feb 2026 17:26:25 +1100
> > Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> >
> > > On Wed, Feb 4, 2026 at 4:07 PM Yugo Nagata <nagata(at)sraoss(dot)co(dot)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