> In fact, the WAL sender always starts reading WAL from restart_lsn,
> which in turn is always <= confirmed_flush_lsn. While reading WAL, WAL
> sender may read XLOG_RUNNING_XACTS WAL record with lsn <=
> confirmed_flush_lsn. While processing XLOG_RUNNING_XACTS record it may
> update its restart_lsn and catalog_xmin with current_lsn = lsn fo
> XLOG_RUNNING_XACTS record. In this situation current_lsn <=
> confirmed_flush_lsn.
This can only happen when the WAL sender is restarted. However in
this case, the restart_lsn and catalog_xmin should have already been
persisted by the previous run of the WAL sender.
I still doubt these calls are necessary. I think there is a
complicated chicken and egg problem here. Here is my logic:
1) LogicalConfirmReceivedLocation() is called explicitly when
confirmed_flush is sent by the replication client.
2) LogicalConfirmReceivedLocation() is the only place that updates
confirmed_flush.
3) The replication client can only send a confirmed_flush for a
current_lsn it has already received.
4) These two functions have already run for any current_lsn the
replication client has received.
5) These two functions call LogicalConfirmReceivedLocation() only if
current_lsn <= confirmed_flush.
Thank you for your patience.