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 <simon@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