Hi, GetOldestXmin() applies vacuum_defer_cleanup_age only when !RecoveryInProgress(). In contrast to that GetSnapshotData() applies it unconditionally.
I'm not actually clear whether including vacuum_defer_cleanup_age on a replica is meaningful. But it strikes me as odd to have that behavioural difference between GetOldestXmin() and GetSnapshotData() - without any need, as far as I can tell? The difference seems to have been introduced in commit bca8b7f16a3e720794cb0afbdb3733be4f8d9c2c Author: Simon Riggs <si...@2ndquadrant.com> Date: 2011-02-16 19:29:37 +0000 Hot Standby feedback for avoidance of cleanup conflicts on standby. Standby optionally sends back information about oldestXmin of queries which is then checked and applied to the WALSender's proc->xmin. GetOldestXmin() is modified slightly to agree with GetSnapshotData(), so that all backends on primary include WALSender within their snapshots. Note this does nothing to change the snapshot xmin on either master or standby. Feedback piggybacks on the standby reply message. vacuum_defer_cleanup_age is no longer used on standby, though parameter still exists on primary, since some use cases still exist. Simon Riggs, review comments from Fujii Masao, Heikki Linnakangas, Robert Haas without, as far as I can tell, explaining why "vacuum_defer_cleanup_age is no longer used on standby" shouldn't also apply to GetSnapshotData(). I suspect it doesn't hurt all that much to unnecessarily apply vacuum_defer_cleanup_age on a replica. The only thing I see where it matters is that it makes get_actual_variable_endpoint() less accurate, which we probably would like to avoid... Greetings, Andres Freund