RE: How can end users know the cause of LR slot sync delays?

Dear Shlok,

Thanks for updating the patch. Few more comments.

> > > > I’m not sure if this has already been discussed; I couldn’t find any
> > > > mention of it in the thread. Why don’t we persist
> > > > 'slot_sync_skip_reason' (it is outside of
> > > > ReplicationSlotPersistentData)? If a slot wasn’t synced during the
> > > > last cycle and the server restarts, it would be helpful to know the
> > > > reason it wasn’t synced prior to the node restart.
> > > >
> Actually I did not think in this direction. I think it will be useful
> to persist 'slot_sync_skip_reason'. I have made the change for the
> same in the latest patch.

Hmm, I'm wondering it should be written on the disk. Other attributes on the disk
are essential to decode or replicate changes correctly, but sync status is not
used for the purpose. Personally considered, slot sync would re-start soon after
the reboot so that it is OK to start with empty. How about others?

If we want to serialize the info, we should do further tasks:
- update SLOT_VERSION
- make the slot dirty then SaveSlotToPath() when the status is updated.

```
+static void
+update_slot_sync_skip_stats(ReplicationSlot *slot, SlotSyncSkipReason skip_reason)
+{
+ Assert(MyReplicationSlot);
```

I think no need to require *slot as an argument. We can use the variable to shorten
like update_local_synced_slot().

```
# Verify pg_sync_replication_slots is failing
ok( $stderr =~ /skipping slot synchronization because the received slot sync/,
'pg_sync_replication_slots failed as expected');
```

This may be matter of taste, but can you check whole of log message? Latter part
indicates the actual reason.

```
# Detach injection point
$standby->safe_psql(
'postgres', q{
SELECT injection_points_detach('slot-sync-skip');
SELECT injection_points_wakeup('slot-sync-skip');
});
```

Not mandatory, but you can quit the background session if you release the
injection point.

Best regards,
Hayato Kuroda
FUJITSU LIMITED