On Wed, Aug 13, 2025, at 12:40 AM, SATYANARAYANA NARLAPURAM wrote:
> I couldn't find a previous discussion on a new GUC to globally enable
> or disable logical subscription workers at the instance level. So
> starting a new thread on this.
>
max_logical_replication_workers.
> In multi-region or high-availability setups, a promoted standby often
> requires a controlled switchover before it should start applying
> logical replication changes from upstream. Without such control, a
> promoted standby may immediately attempt to connect to the publisher as
> a logical subscriber, which can cause it to unexpectedly take over
> replication slots, start pulling changes before the setup is ready, or
> even conflict with the original primary that is still using those
> slots. Disabling the subscription on the primary before promoting a
> standby is not possible in all cases, for example during PITR or data
> center outages.
> Providing a way to keep logical subscriptions globally disabled—via a
> GUC setting—prior to promotion ensures that no changes are accidentally
> pulled or applied before the system is fully prepared. This avoids race
> conditions and the risk of data divergence.
>
Why do you need another GUC? The max_logical_replication_workers parameter is
useful for this exact scenario. For example, pg_createsubscriber uses it to not
start logical replication while converting a physical replica into a logical
one.
> I would like to propose adding a GUC with the following behavior:
> 1. Default value for the GUC is ON, same behavior as now without the
> GUC
> 2. When off, no new apply workers start and existing ones exit
> gracefully similar to when subscription disabled
> 3. When turned on again, behavior will be the same as the current
> behavior
> 4. This GUC shouldn't require a restart
>
That's the only point not covered by the current behavior. You don't explain
why it is a requirement.
--
Euler Taveira
EDB https://www.enterprisedb.com/
