On Mon, Nov 29, 2021 at 1:48 AM SATYANARAYANA NARLAPURAM <satyanarlapu...@gmail.com> wrote: > >> 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? > > Standby pulling the information or at least making a first attempt to connect > to the primary is a better design as primary doesn't need to spend its > cycles repeatedly connecting to an unreachable standby. In fact, primary > wouldn't even need to know the followers, for example followers / log > shipping standbys
My idea was to let the existing walsender from the primary/publisher to send the slot info (both logical and physical replication slots) to the standby/subscriber, probably by piggybacking the slot info with the WAL currently it sends. Having said that, I don't know the feasibility of it. Anyways, I'm not in favour of having a new bg worker to just ship the slot info. The standby/subscriber, while making connection to primary/publisher, can choose to get the replication slot info. As I said upthread, the problem I see with standby/subscriber pulling the info is that: how frequently the standby/subscriber is going to sync the slot info from primary/publisher? How can it ensure that the latest information exists say when the subscriber is down/crashed before it picks up the latest slot information? IIUC, the initial idea proposed in this patch deals with only logical replication slots not the physical replication slots, what I'm thinking is to have a generic way to deal with both of them. Note: In the above description, I used primary-standby and publisher-subscriber to represent the physical and logical replication slots respectively. Regards, Bharath Rupireddy.
