Re: Proposal: GUC to control starting/stopping logical subscription workers

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: "SATYANARAYANA NARLAPURAM" <satyanarlapuram(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal: GUC to control starting/stopping logical subscription workers
Date: 2025-09-11 00:11:36
Message-ID: ae7220d6-841f-426e-8ab6-8b2c0a8edf88@app.fastmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-09-11 00:54:00 Re: Display is_prev_bucket_same_wrt of xl_hash_squeeze_page
Previous Message Alexandra Wang 2025-09-10 23:56:40 Re: SQL:2023 JSON simplified accessor support