Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 - Mailing list pgsql-hackers

From Peter Smith
Subject Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0
Date
Msg-id CAHut+PuwcjxDZ7XV1_pNedzckrYggc3oCJXa2Bi9Aroadatozg@mail.gmail.com
Whole thread Raw
In response to RE: Warn when creating or enabling a subscription with max_logical_replication_workers = 0  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Responses Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Decoupling our alignment assumptions about int64 and double
Next
From: Jeremy Schneider
Date:
Subject: Re: client_connection_check_interval default value