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/
