> 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.
