Dear Shveta, I resumed to check the thread. Here are my high-level comments. Sorry if you have been already discussed.
01. General I think the documentation can be added, not only GUCs. How about adding examples for combinations of physical and logical replications? You can say that both of physical primary can be publisher and slots on primary/standby are synchronized. 02. General standby_slot_names ensures that physical standby is always ahead subscriber, but I think it may be not sufficient. There is a possibility that primary server does not have any physical slots. In this case the physical standby may be behind the subscriber and the system may be confused when the failover is occured. Can't we specify the name of standby via application_name or something? 03. General In this architecture, the syncslot worker is launched per db and they independently connects to primary, right? I'm not sure it is efficient, but I come up with another architecture - only a worker (syncslot receiver)connects to the primary and other workers (syncslot worker) receives infos from it and updates. This can reduce the number of connections so that it may slightly improve the latency of network. How do you think? 04. General test file recovery/t/051_slot_sync.pl is missing. 04. ReplSlotSyncMain Does the worker have to connect to the specific database? ``` /* Connect to our database. */ BackgroundWorkerInitializeConnectionByOid(MySlotSyncWorker->dbid, MySlotSyncWorker->userid, 0); ``` 05. SlotSyncInitSlotNamesLst() "Lst" should be "List". Best Regards, Hayato Kuroda FUJITSU LIMITED