Hello, hackers. Working on some stuff, I realized I do not understand why latestRemovedXid|cuteoff_xid (in different types of WAL records) are sent every time they appear on the primary side.
latestRemovedXid|cuteoff_xid is used to call ResolveRecoveryConflictWithSnapshot and cancel conflicting backend on Standby. In some of the cases, snapshot conflict resolving is the only work REDO does (heap_xlog_cleanup_info or btree_xlog_reuse_page, for example). Could we try to somehow optimistically advance the latest sent latestRemovedXid value in shared memory on the primary and skip sending it if the newer xid was sent already? In such a way we could reduce the number of ResolveRecoveryConflictWithSnapshot calls on Standby and even skip some WAL records. At least we could do the same optimization on the standby side (skipping ResolveRecoveryConflictWithSnapshot if it was called with newer xid already). Is it a sane idea or I have missed something huge? Thanks, Michail.
