Re: Synchronizing slots from primary to standby - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Synchronizing slots from primary to standby
Date
Msg-id 0ee342de-4422-809f-8e4d-fbd99370bed9@enterprisedb.com
Whole thread Raw
In response to Re: Synchronizing slots from primary to standby  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Synchronizing slots from primary to standby  ("Hsu, John" <hsuchen@amazon.com>)
List pgsql-hackers
On 28.11.21 07:52, Bharath Rupireddy wrote:
> 1) Instead of a new LIST_SLOT command, can't we use
> READ_REPLICATION_SLOT (slight modifications needs to be done to make
> it support logical replication slots and to get more information from
> the subscriber).

I looked at that but didn't see an obvious way to consolidate them. 
This is something we could look at again later.

> 2) How frequently the new bg worker is going to sync the slot info?
> How can it ensure that the latest information exists say when the
> subscriber is down/crashed before it picks up the latest slot
> information?

The interval is currently hardcoded, but could be a configuration 
setting.  In the v2 patch, there is a new setting that orders physical 
replication before logical so that the logical subscribers cannot get 
ahead of the physical standby.

> 3) Instead of the subscriber pulling the slot info, why can't the
> publisher (via the walsender or a new bg worker maybe?) push the
> latest slot info? I'm not sure we want to add more functionality to
> the walsender, if yes, isn't it going to be much simpler?

This sounds like the failover slot feature, which was rejected.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Synchronizing slots from primary to standby
Next
From: Joshua Brindle
Date:
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs