MIME-Version: 1.0
References: <20260204140731.0e4b511906ac748abad1f3d9@sraoss.co.jp>
 <CAHut+Pt5KzE75ZyFZPC2fcb+GRes2DbHAh_vgfdDXoWmEV6hAg@mail.gmail.com>
 <20260205101239.3c432a7766bc962bad9c6c51@sraoss.co.jp> <CAHut+Pto3FdeAaQJgcXZHk8qOnGOTpWW7K98mxzVckgQjWWXHw@mail.gmail.com>
 <TY4PR01MB1690799DBFDC5EDA4630D61619499A@TY4PR01MB16907.jpnprd01.prod.outlook.com>
In-Reply-To: <TY4PR01MB1690799DBFDC5EDA4630D61619499A@TY4PR01MB16907.jpnprd01.prod.outlook.com>
From: Peter Smith <smithpb2250@gmail.com>
Date: Fri, 6 Feb 2026 09:58:02 +1100
Message-ID: <CAHut+PuwcjxDZ7XV1_pNedzckrYggc3oCJXa2Bi9Aroadatozg@mail.gmail.com>
Subject: Re: Warn when creating or enabling a subscription with
 max_logical_replication_workers = 0
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: Yugo Nagata <nagata@sraoss.co.jp>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAHut%2BPuwcjxDZ7XV1_pNedzckrYggc3oCJXa2Bi9Aroadatozg%40mail.gmail.com>
Precedence: bulk

On Thu, Feb 5, 2026 at 7:12=E2=80=AFPM 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=E2=80=AFPM Yugo Nagata <nagata@sraoss.co.j=
p> 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 "worker=
s", but in
> > fact, because max_logical_replication_workers =3D 0 the main "logical
> > replication launcher" process had failed to start, so logical replicati=
on was
> > entirely disabled.
> >
> > See code: in backend/replication/logical/launcher.c
> >
> > ApplyLauncherRegister(void)
> > {
> > ...
> >   if (max_logical_replication_workers =3D=3D 0 || IsBinaryUpgrade)
> >     return;
> >
> > ~~~
> >
> > Given this, I felt that instead of testing the GUC, what you really wan=
t 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 !=3D 0)
> >                 kill(LogicalRepCtx->launcher_pid, SIGUSR1);
> > +       else
> > +       {
> > +               if (max_logical_replication_workers =3D=3D 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 mig=
ht fail
> for some reasons and restart soon (pid will be set to 0), in which case t=
his
> warning wouldn't be appropriate.

AFAIK, that's not possible. My warning is guarded by checking
max_logical_replication_workers =3D=3D 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 =3D 1

----------
test_sub=3D# create subscription sub1 connection 'dbname=3Dtest_pub'
publication pub1;
NOTICE:  created replication slot "sub1" on publisher
CREATE SUBSCRIPTION
test_sub=3D# 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".
...
----------

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