Review for v41 patch. 1. ====== src/backend/utils/misc/postgresql.conf.sample
+#enable_syncslot = on # enables slot synchronization on the physical standby from the primary enable_syncslot is disabled by default, so, it should be 'off' here. ~~~ 2. IIUC, the slotsyncworker's connection to the primary is to execute a query. Its aim is not walsender type connection, but at primary when queried, the 'backend_type' is set to 'walsender'. Snippet from primary db- datname | usename | application_name | wait_event_type | backend_type ---------+-------------+------------------+-----------------+-------------- postgres | replication | slotsyncworker | Client | walsender Is it okay? ~~~ 3. As per current logic, If there are slots on primary with disabled subscriptions, then, when standby is created it replicates these slots but can't make them sync-ready until any activity happens on the slots. So, such slots stay in 'i' sync-state and get dropped when failover happens. Now, if the subscriber tries to enable their existing subscription after failover, it gives an error that the slot does not exist. ~~~ 4. primary_slot_name GUC value test: When standby is started with a non-existing primary_slot_name, the wal-receiver gives an error but the slot-sync worker does not raise any error/warning. It is no-op though as it has a check 'if (XLogRecPtrIsInvalid(WalRcv->latestWalEnd)) do nothing'. Is this okay or shall the slot-sync worker too raise an error and exit? In another case, when standby is started with valid primary_slot_name, but it is changed to some invalid value in runtime, then walreceiver starts giving error but the slot-sync worker keeps on running. In this case, unlike the previous case, it even did not go to no-op mode (as it sees valid WalRcv->latestWalEnd from the earlier run) and keep pinging primary repeatedly for slots. Shall here it should error out or at least be no-op until we give a valid primary_slot_name? -- Thanks, Nisha
