| From: | Peter Smith <smithpb2250(at)gmail(dot)com> |
|---|---|
| To: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
| Cc: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 |
| Date: | 2026-02-05 22:58:02 |
| Message-ID: | CAHut+PuwcjxDZ7XV1_pNedzckrYggc3oCJXa2Bi9Aroadatozg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 5, 2026 at 7:12 PM Zhijie Hou (Fujitsu)
<houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
> 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:
> > >
...
> >
> > 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeremy Schneider | 2026-02-05 23:04:52 | Re: client_connection_check_interval default value |
| Previous Message | Andres Freund | 2026-02-05 22:00:42 | Re: Decoupling our alignment assumptions about int64 and double |