public inbox for [email protected]help / color / mirror / Atom feed
RE: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 5+ messages / 3 participants [nested] [flat]
* RE: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 @ 2026-02-05 08:12 Zhijie Hou (Fujitsu) <[email protected]> 2026-02-05 22:58 ` Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Peter Smith <[email protected]> 0 siblings, 1 reply; 5+ messages in thread From: Zhijie Hou (Fujitsu) @ 2026-02-05 08:12 UTC (permalink / raw) To: Peter Smith <[email protected]>; Yugo Nagata <[email protected]>; +Cc: pgsql-hackers On Thursday, February 5, 2026 3:47 PM Peter Smith <[email protected]> wrote: > On Thu, Feb 5, 2026 at 12:12 PM Yugo Nagata <[email protected]> wrote: > > > > On Wed, 4 Feb 2026 17:26:25 +1100 > > Peter Smith <[email protected]> wrote: > > > > > On Wed, Feb 4, 2026 at 4:07 PM Yugo Nagata <[email protected]> > 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 ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 2026-02-05 08:12 RE: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Zhijie Hou (Fujitsu) <[email protected]> @ 2026-02-05 22:58 ` Peter Smith <[email protected]> 2026-02-06 04:37 ` Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Yugo Nagata <[email protected]> 0 siblings, 1 reply; 5+ messages in thread From: Peter Smith @ 2026-02-05 22:58 UTC (permalink / raw) To: Zhijie Hou (Fujitsu) <[email protected]>; +Cc: Yugo Nagata <[email protected]>; pgsql-hackers On Thu, Feb 5, 2026 at 7:12 PM Zhijie Hou (Fujitsu) <[email protected]> wrote: > > On Thursday, February 5, 2026 3:47 PM Peter Smith <[email protected]> wrote: > > On Thu, Feb 5, 2026 at 12:12 PM Yugo Nagata <[email protected]> wrote: > > > > > > On Wed, 4 Feb 2026 17:26:25 +1100 > > > Peter Smith <[email protected]> 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 ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 2026-02-05 08:12 RE: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Zhijie Hou (Fujitsu) <[email protected]> 2026-02-05 22:58 ` Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Peter Smith <[email protected]> @ 2026-02-06 04:37 ` Yugo Nagata <[email protected]> 2026-02-06 07:28 ` Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Peter Smith <[email protected]> 0 siblings, 1 reply; 5+ messages in thread From: Yugo Nagata @ 2026-02-06 04:37 UTC (permalink / raw) To: Peter Smith <[email protected]>; +Cc: Zhijie Hou (Fujitsu) <[email protected]>; pgsql-hackers On Fri, 6 Feb 2026 09:58:02 +1100 Peter Smith <[email protected]> wrote: > On Thu, Feb 5, 2026 at 7:12 PM Zhijie Hou (Fujitsu) > <[email protected]> wrote: > > > > On Thursday, February 5, 2026 3:47 PM Peter Smith <[email protected]> wrote: > > > On Thu, Feb 5, 2026 at 12:12 PM Yugo Nagata <[email protected]> wrote: > > > > > > > > On Wed, 4 Feb 2026 17:26:25 +1100 > > > > Peter Smith <[email protected]> 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. I also initially considered emitting the warning in ApplyLauncherWakeup() after checking max_logical_replication_workers == 0. However, I think checking pid == 0 is sufficient. Even when max_logical_replication_workers is non-zero and the launcher is normally running, it could still be killed by user action or by the OS, although such cases should be rare. In that situation, emitting the same warning would not be appropriate. I placed the logic in subscriptioncmds.c so that the warning message can better reflect the actual situation, while keeping consistency with existing messages such as "subscription was created, but is not connected". > > > > 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. Yes. In this case, warnings are emitted to the server log, but they do not appear as a response to CREATE/ALTER SUBSCRIPTION. There is an option to also emit such warnings during the CREATE/ALTER SUBSCRIPTION command, so I will update the patch accordingly. Nevertheless, this seems to be a different situation from the case where logical replication is disabled entirely, so I think the warning messages should be handled separately. Regards, Yugo Nagata -- Yugo Nagata <[email protected]> ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 2026-02-05 08:12 RE: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Zhijie Hou (Fujitsu) <[email protected]> 2026-02-05 22:58 ` Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Peter Smith <[email protected]> 2026-02-06 04:37 ` Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Yugo Nagata <[email protected]> @ 2026-02-06 07:28 ` Peter Smith <[email protected]> 2026-04-13 07:04 ` Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Yugo Nagata <[email protected]> 0 siblings, 1 reply; 5+ messages in thread From: Peter Smith @ 2026-02-06 07:28 UTC (permalink / raw) To: Yugo Nagata <[email protected]>; +Cc: Zhijie Hou (Fujitsu) <[email protected]>; pgsql-hackers On Fri, Feb 6, 2026 at 3:37 PM Yugo Nagata <[email protected]> wrote: > > On Fri, 6 Feb 2026 09:58:02 +1100 > Peter Smith <[email protected]> wrote: > > > On Thu, Feb 5, 2026 at 7:12 PM Zhijie Hou (Fujitsu) > > <[email protected]> wrote: > > > > > > On Thursday, February 5, 2026 3:47 PM Peter Smith <[email protected]> wrote: > > > > On Thu, Feb 5, 2026 at 12:12 PM Yugo Nagata <[email protected]> wrote: > > > > > > > > > > On Wed, 4 Feb 2026 17:26:25 +1100 > > > > > Peter Smith <[email protected]> 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. > > I also initially considered emitting the warning in > ApplyLauncherWakeup() after checking max_logical_replication_workers == 0. > However, I think checking pid == 0 is sufficient. > > Even when max_logical_replication_workers is non-zero and the launcher is > normally running, it could still be killed by user action or by the > OS, although such cases should be rare. In that situation, emitting the > same warning would not be appropriate. Sorry, I did not understand the previous paragraph. If "when max_logical_replication_workers is non-zero" then the warning cannot be emitted inappropriately because that warning is guarded by "if (max_logical_replication_workers == 0)" (??). > > I placed the logic in subscriptioncmds.c so that the warning message can > better reflect the actual situation, while keeping consistency with > existing messages such as "subscription was created, but is not > connected". In hindsgght your original patch is very similar to what I posted. I agree, your messages are better because they are more specific. But there are multiple calls to ApplyLauncherWakeup() -- not just those 2 that you handled - so I was just unsure if there are some remaining holes. > > > > > > > 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. > > Yes. In this case, warnings are emitted to the server log, but they do not > appear as a response to CREATE/ALTER SUBSCRIPTION. There is an option to > also emit such warnings during the CREATE/ALTER SUBSCRIPTION command, so > I will update the patch accordingly. > > Nevertheless, this seems to be a different situation from the case where > logical replication is disabled entirely, so I think the warning messages > should be handled separately. +1. I also think that running out of worker resources is a different scenario from the entire logical replication being disabled, so it should be handled separately ====== Kind Regards, Peter Smith. Fujitsu Australia ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 2026-02-05 08:12 RE: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Zhijie Hou (Fujitsu) <[email protected]> 2026-02-05 22:58 ` Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Peter Smith <[email protected]> 2026-02-06 04:37 ` Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Yugo Nagata <[email protected]> 2026-02-06 07:28 ` Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Peter Smith <[email protected]> @ 2026-04-13 07:04 ` Yugo Nagata <[email protected]> 0 siblings, 0 replies; 5+ messages in thread From: Yugo Nagata @ 2026-04-13 07:04 UTC (permalink / raw) To: Peter Smith <[email protected]>; +Cc: Zhijie Hou (Fujitsu) <[email protected]>; pgsql-hackers On Fri, 6 Feb 2026 18:28:06 +1100 Peter Smith <[email protected]> wrote: > On Fri, Feb 6, 2026 at 3:37 PM Yugo Nagata <[email protected]> wrote: > > > > On Fri, 6 Feb 2026 09:58:02 +1100 > > Peter Smith <[email protected]> wrote: > > > > > On Thu, Feb 5, 2026 at 7:12 PM Zhijie Hou (Fujitsu) > > > <[email protected]> wrote: > > > > > > > > On Thursday, February 5, 2026 3:47 PM Peter Smith <[email protected]> wrote: > > > > > On Thu, Feb 5, 2026 at 12:12 PM Yugo Nagata <[email protected]> wrote: > > > > > > > > > > > > On Wed, 4 Feb 2026 17:26:25 +1100 > > > > > > Peter Smith <[email protected]> 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. > > > > I also initially considered emitting the warning in > > ApplyLauncherWakeup() after checking max_logical_replication_workers == 0. > > However, I think checking pid == 0 is sufficient. > > > > Even when max_logical_replication_workers is non-zero and the launcher is > > normally running, it could still be killed by user action or by the > > OS, although such cases should be rare. In that situation, emitting the > > same warning would not be appropriate. > > Sorry, I did not understand the previous paragraph. If "when > max_logical_replication_workers is non-zero" then the warning cannot > be emitted inappropriately because that warning is guarded by "if > (max_logical_replication_workers == 0)" (??). You're right, I misunderstood that part. Sorry about that. > > I placed the logic in subscriptioncmds.c so that the warning message can > > better reflect the actual situation, while keeping consistency with > > existing messages such as "subscription was created, but is not > > connected". > > In hindsgght your original patch is very similar to what I posted. I > agree, your messages are better because they are more specific. But > there are multiple calls to ApplyLauncherWakeup() -- not just those 2 > that you handled - so I was just unsure if there are some remaining > holes. I see your point. There are other places where ApplyLauncherWakeupAtCommit() is called, for example via AlterSubscription() when retain_dead_tuples is set or when the owner is changed. However, these cases are not affected when max_logical_replication_workers = 0 unless the subscription is enabled. For now, I’ll keep the current approach. > > > > > > > > > > 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. > > > > Yes. In this case, warnings are emitted to the server log, but they do not > > appear as a response to CREATE/ALTER SUBSCRIPTION. There is an option to > > also emit such warnings during the CREATE/ALTER SUBSCRIPTION command, so > > I will update the patch accordingly. > > > > Nevertheless, this seems to be a different situation from the case where > > logical replication is disabled entirely, so I think the warning messages > > should be handled separately. > > +1. I also think that running out of worker resources is a different > scenario from the entire logical replication being disabled, so it > should be handled separately I've investigated whether we can emit a warning during CREATE/ALTER SUBSCRIPTION when there are no available worker slots to start the subscription. One issue is that, in the current implementation, this condition is only checked when the launcher actually forks a worker. There is no infrastructure to perform this check in advance from a backend process. Adding such infrastructure would likely require acquiring an LWLock (at least in shared mode) to inspect the current worker state. Moreover, even if we implement such a mechanism, the situation may change between the time of the check and the actual worker startup. Given these limitations, I'm wondering whether introducing this kind of warning is worthwhile. Regards, Yugo Nagata -- Yugo Nagata <[email protected]> ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2026-04-13 07:04 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-02-05 08:12 RE: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 Zhijie Hou (Fujitsu) <[email protected]> 2026-02-05 22:58 ` Peter Smith <[email protected]> 2026-02-06 04:37 ` Yugo Nagata <[email protected]> 2026-02-06 07:28 ` Peter Smith <[email protected]> 2026-04-13 07:04 ` Yugo Nagata <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox