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