The standby's snapshot conflict machinery is driven by cleanup records replayed from the primary, and not all of those records originate in VACUUM. That distinction matters when snapshot conflicts show up in setups where the usual suspects — a slot-less standby, a walsender restart, or hot_standby_feedback toggling — are not in play.
The GetOldestXmin() comment in src/backend/storage/ipc/procarray.c (as of version 13) states the underlying constraint directly: data is only protected if the walsender runs continuously while queries are executed on the standby. Gaps in that continuity are one route to a conflict:
- The standby uses no physical replication slot, the walsender reboots, and
VACUUMruns before walreceiver sends the next status update. hot_standby_feedbackis turned off and back on for a standby.
Those cases do not account for conflicts observed in environments where neither occurs, which shifts the likely cause toward cleanup records unrelated to VACUUM.
Records that trigger conflict resolution
ResolveRecoveryConflictWithSnapshot is the function that finds conflicting xvids on the standby and terminates the conflicting backends. Searching for its callers turns up the following cleanup records:
XLOG_GIST_DELETEXLOG_GIST_PAGE_REUSEXLOG_HASH_VACUUM_ONE_PAGEXLOG_HEAP2_CLEANUP_INFOXLOG_HEAP2_CLEANXLOG_HEAP2_VISIBLEXLOG_HEAP2_FREEZE_PAGEXLOG_BTREE_DELETEXLOG_BTREE_REUSE_PAGEXLOG_SPGIST_VACUUM_REDIRECT
Most are produced by VACUUM and are therefore avoidable through hot_standby_feedback. A smaller set appears to be generatable outside VACUUM:
XLOG_GIST_DELETE— new tuple insertion for a GiST indexXLOG_GIST_PAGE_REUSE— new index page creation for a GiST indexXLOG_HEAP2_CLEAN— early page pruning for HOT chains (?)XLOG_BTREE_DELETE— index deduplication on writesXLOG_BTREE_REUSE_PAGE— index page reuse on writes
This last group is the natural next target of investigation. So far the issue has not been reliably reproduced, and it is not clear which test suites would be best suited to generating these specific cleanup records.



