RE: Synchronizing slots from primary to standby

Dear Shveta,

I resumed to review the patch. I will play more about it, but I can post some
cosmetic comments.

====
walsender.c

01. WalSndWaitForStandbyConfirmation

```
+        sleeptime = WalSndComputeSleeptime(GetCurrentTimestamp());
```

It works well, but I'm not sure whether we should use WalSndComputeSleeptime()
because the function won't be called by walsender.

02.WalSndWaitForStandbyConfirmation

```
+        ConditionVariableTimedSleep(&WalSndCtl->wal_confirm_rcv_cv, sleeptime,
+                                    WAIT_EVENT_WAL_SENDER_WAIT_FOR_STANDBY_CONFIRMATION)
```

Hmm, is it OK to use the same event as WalSndWaitForWal()? IIUC it should be avoided.

03. WalSndShmemInit()

```
+
+        ConditionVariableInit(&WalSndCtl->wal_confirm_rcv_cv);
```

Unnecessary blank?

~~~~~
050_standby_failover_slots_sync.pl

04. General

My pgperltidy modified your test. Please check.

05.

```
# Create publication on the primary
```

Missing "a" before publication?

06.

```
$subscriber1->init(allows_streaming => 'logical');
...
$subscriber2->init(allows_streaming => 'logical');
```

IIUC, these settings are not needed.

07.

```
my $primary_insert_time = time();
```

The variable is not used.

08.

```
# Stop the standby associated with the specified physical replication slot so
# that the logical replication slot won't receive changes until the standby
# slot's restart_lsn is advanced or the slot is removed from the
# standby_slot_names list
```

Missing comma?

09.

```
$back_q->query_until(qr//,
    "SELECT pg_logical_slot_get_changes('test_slot', NULL, NULL);\n");
```

Not sure, should we have to close the back_q connection?

10.

```
# Remove the standby from the standby_slot_names list and reload the
# configuration
$primary->adjust_conf('postgresql.conf', 'standby_slot_names', "''");
$primary->psql('postgres', "SELECT pg_reload_conf()");
```

a.
Missing comma?

b.
I counted and reload function in perl (e.g., `$primary->reload;`) is more often to
be used. Do you have a reason to use pg_reload_conf()?

11.

```
# Now that the standby lsn has advanced, the primary must send the decoded
# changes to the subscription.
$publisher->wait_for_catchup('regress_mysub1');
```

Is the comment correct? I think primary sends data because the GUC is modified.

12.

```
# Put the standby back on the primary_slot_name for the rest of the tests
$primary->adjust_conf('postgresql.conf', 'standby_slot_names', 'sb1_slot');
$primary->restart();
```

Just to confirm - you used restart() here because we must ensure the GUC change is
propagated to all backends, right?

~~~~~
wait_event_names.txt

13.

```
+WAL_SENDER_WAIT_FOR_STANDBY_CONFIRMATION    "Waiting for the WAL to be received by physical standby in WAL sender
process."
```

But there is a possibility that backend processes may wait with the event, right?

Best Regards,
Hayato Kuroda
FUJITSU LIMITED