I'm poking around to see debug a vacuuming problem and wondering if I've found something more serious.
As far as I can tell the snapshots on HOT standby are built using a list of running xids that the primary builds and puts in the WAL and that seems to include all xids from transactions running in all databases. The HOT standby would then build a snapshot and eventually send the xmin of that snapshot back to the primary in the hot standby feedback and that would block vacuuming tuples that might be visible to the standby. Many ages ago Alvaro sweated blood to ensure vacuums could run for long periods of time without holding back the xmin horizon and blocking other vacuums from cleaning up tuples. That's the purpose of the excludeVacuum flag in GetCurrentVirtualXIDs(). That's possible because we know vacuums won't insert any tuples that queries might try to view and also vacuums won't try to perform any sql queries on other tables. I can't find anywhere that the standby snapshot building mechanism gets this same information about which xids are actually vacuums that can be ignored when building a snapshot. So I'm concerned that the hot standby sending back its xmin would be effectively undermining this mechanism and forcing vacuum xids to be included in the xmin horizon and prevent vacuuming of tuples. Am I missing something obvious? Is this a known problem? -- greg
