MIME-Version: 1.0
References: <20260204140731.0e4b511906ac748abad1f3d9@sraoss.co.jp>
 <CAHut+Pt5KzE75ZyFZPC2fcb+GRes2DbHAh_vgfdDXoWmEV6hAg@mail.gmail.com> <20260205101239.3c432a7766bc962bad9c6c51@sraoss.co.jp>
In-Reply-To: <20260205101239.3c432a7766bc962bad9c6c51@sraoss.co.jp>
From: Peter Smith <smithpb2250@gmail.com>
Date: Thu, 5 Feb 2026 18:46:58 +1100
Message-ID: <CAHut+Pto3FdeAaQJgcXZHk8qOnGOTpWW7K98mxzVckgQjWWXHw@mail.gmail.com>
Subject: Re: Warn when creating or enabling a subscription with
 max_logical_replication_workers = 0
To: Yugo Nagata <nagata@sraoss.co.jp>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/mixed; boundary="0000000000002b2438064a0ee2ef"
Archived-At: <https://www.postgresql.org/message-id/CAHut%2BPto3FdeAaQJgcXZHk8qOnGOTpWW7K98mxzVckgQjWWXHw%40mail.gmail.com>
Precedence: bulk

--0000000000002b2438064a0ee2ef
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 5, 2026 at 12:12=E2=80=AFPM Yugo Nagata <nagata@sraoss.co.jp> w=
rote:
>
> On Wed, 4 Feb 2026 17:26:25 +1100
> Peter Smith <smithpb2250@gmail.com> wrote:
>
> > On Wed, Feb 4, 2026 at 4:07=E2=80=AFPM 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 th=
is
> > > case, the CREATE/ALTER SUBSCRIPTION command completes successfully wi=
thout
> > > any warning, making it difficult to notice that logical replication c=
annot
> > > start.
> > >
> > > Of course, users can confirm whether logical replication is working b=
y
> > > checking system views such as pg_stat_replication or pg_stat_subscrip=
tion.
> > > 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 t=
o
> 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 =3D 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 =3D=3D 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 !=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"));
+       }
 }
------


AND THE RESULT:

----------
test_sub=3D# create subscription sub1 connection 'dbname=3Dtest_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=3D#
test_sub=3D# alter subscription sub1 disable;
ALTER SUBSCRIPTION
test_sub=3D# alter subscription sub1 enable;
WARNING:  Logical replication is currently disabled
HINT:  "max_logical_replication_workers" is 0
ALTER SUBSCRIPTION
test_sub=3D#
----------

IIUC, that seems to be giving the CREATE/ALTER warnings that you wanted.

Thoughts?

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

--0000000000002b2438064a0ee2ef
Content-Type: text/plain; charset="US-ASCII"; name="PS_warn_no_launcher.txt"
Content-Disposition: attachment; filename="PS_warn_no_launcher.txt"
Content-Transfer-Encoding: base64
Content-ID: <f_ml95iv7v0>
X-Attachment-Id: f_ml95iv7v0

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL3JlcGxpY2F0aW9uL2xvZ2ljYWwvbGF1bmNoZXIuYyBi
L3NyYy9iYWNrZW5kL3JlcGxpY2F0aW9uL2xvZ2ljYWwvbGF1bmNoZXIuYwppbmRleCAzZWQ4NjQ4
MGJlMi4uZjg4MDM4MGNlNGUgMTAwNjQ0Ci0tLSBhL3NyYy9iYWNrZW5kL3JlcGxpY2F0aW9uL2xv
Z2ljYWwvbGF1bmNoZXIuYworKysgYi9zcmMvYmFja2VuZC9yZXBsaWNhdGlvbi9sb2dpY2FsL2xh
dW5jaGVyLmMKQEAgLTExOTUsNiArMTE5NSwxMyBAQCBBcHBseUxhdW5jaGVyV2FrZXVwKHZvaWQp
CiB7CiAJaWYgKExvZ2ljYWxSZXBDdHgtPmxhdW5jaGVyX3BpZCAhPSAwKQogCQlraWxsKExvZ2lj
YWxSZXBDdHgtPmxhdW5jaGVyX3BpZCwgU0lHVVNSMSk7CisJZWxzZQorCXsKKwkJaWYgKG1heF9s
b2dpY2FsX3JlcGxpY2F0aW9uX3dvcmtlcnMgPT0gMCkKKwkJCWVyZXBvcnQoV0FSTklORywKKwkJ
CQllcnJtc2coIkxvZ2ljYWwgcmVwbGljYXRpb24gaXMgY3VycmVudGx5IGRpc2FibGVkIiksCisJ
CQkJZXJyaGludCgiXCIlc1wiIGlzIDAuIiwgIm1heF9sb2dpY2FsX3JlcGxpY2F0aW9uX3dvcmtl
cnMiKSk7CisJfQogfQogCiAvKgo=
--0000000000002b2438064a0ee2ef--