forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commitf3c15cb
committed
Generalize how VACUUM skips all-frozen pages.
Non-aggressive VACUUMs were at a gratuitous disadvantage (relative toaggressive VACUUMs) around advancing relfrozenxid and relminmxid beforenow. The issue only came up when concurrent activity unset some heappage's visibility map bit right as VACUUM was considering if the pageshould get counted in frozenskipped_pages. The non-aggressive casewould recheck the all-frozen bit at this point. The aggressive casereasoned that the page (a skippable page) must have at least beenall-frozen in the recent past, so skipping it won't make relfrozenxidadvancement unsafe (which is never okay for aggressive VACUUMs).The recheck created a window for some other backend to confuse mattersfor VACUUM. If the page's VM bit turned out to be unset, VACUUM wouldconclude that the page was _never_ all-frozen. frozenskipped_pages wasnot incremented, and yet VACUUM couldn't back out of skipping at thislate stage (it couldn't choose to scan the page instead). This made itunsafe to advance relfrozenxid later on.Consistently avoid the issue by generalizing how we skip frozen pagesduring aggressive VACUUMs: take the same approach when skipping anyskippable page range during aggressive and non-aggressive VACUUMs alike.The new approach makes ranges (not individual pages) the fundamentalunit of skipping using the visibility map. frozenskipped_pages isreplaced with a boolean flag that represents whether some skippablerange with one or more all-visible pages was actually skipped.It is safe for VACUUM to treat a page as all-frozen provided it at leasthad its all-frozen bit set after the OldestXmin cutoff was established.VACUUM is only required to scan pages that might have XIDs < OldestXmin(unfrozen XIDs) to be able to safely advance relfrozenxid. Tuplesconcurrently inserted on "skipped" pages can be thought of as equivalentto tuples concurrently inserted on a block >= rel_pages.It's possible that the issue this commit fixes hardly ever came up inpractice. But we only had to be unlucky once to lose out on advancingrelfrozenxid -- a single affected heap page was enough to throw VACUUMoff. That seems like something to avoid on general principle. This issimilar to an issue fixed by commit44fa848, which taught vacuumlazy.cto not give up on non-aggressive relfrozenxid advancement just because acleanup lock wasn't immediately available on some heap page.Skipping an all-visible range is now explicitly structured as a choicemade by non-aggressive VACUUMs, by weighing known costs (scanning extraskippable pages to freeze their tuples early) against known benefits(advancing relfrozenxid early). This works in essentially the same wayas it always has (don't skip ranges < SKIP_PAGES_THRESHOLD). We coulddo much better here in the future by considering other relevant factors.Author: Peter Geoghegan <pg@bowt.ie>Reviewed-By: Robert Haas <robertmhaas@gmail.com>Discussion:https://postgr.es/m/CAH2-Wzn6bGJGfOy3zSTJicKLw99PHJeSOQBOViKjSCinaxUKDQ@mail.gmail.comDiscussion:https://postgr.es/m/CA%2BTgmoZiSOY6H7aadw5ZZGm7zYmfDzL6nwmL5V7GL4HgJgLF_w%40mail.gmail.com1 parent0b018fa commitf3c15cb
1 file changed
+146
-163
lines changed0 commit comments
Comments
(0)