On Thu, Mar 29, 2018 at 4:47 PM, Greg Stark <st...@mit.edu> wrote: > 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. >
I think the vacuum assigns xids only if it needs to truncate some of the pages in the relation which happens towards the end of vacuum. So, it shouldn't hold back the xmin horizon for long. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
