forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commit44fa848
committed
Simplify lazy_scan_heap's handling of scanned pages.
Redefine a scanned page as any heap page that actually gets pinned byVACUUM's first pass over the heap, regardless of whether or not the pagewas cleanup locked. Although it's fundamentally impossible to prune aheap page without a cleanup lock (since we cannot safely defragment thepage), we can do just about everything else. The only notable furtherexception is freezing tuples, though even that is arguably a consequenceof not being able to prune (not a separate issue).VACUUM now does as much of the same processing as possible for pagesthat could not be cleanup locked. Any failure to do specific requiredprocessing is treated as a special case exception, which will be rare inpractice. We now collect any preexisting LP_DEAD items (left behind byearlier opportunistic pruning) in the dead_items array for these heappages, and count their tuples in the usual way. Steps used to decide ifwe'll attempt relation truncation are performed in the usual way forno-cleanup-lock scanned pages, too.Although eliminating these special cases is intrinsically useful, it'seven more useful as an enabler of further simplifications. The onlyessential difference between aggressive and non-aggressive is that onlyaggressive is _guaranteed_ to be able to advance relfrozenxid up toFreezeLimit. Advancing relfrozenxid is always useful, but before nownon-aggressive VACUUMs threw away the opportunity to do so whenever acleanup lock could not be acquired on any page, no matter what thedetails were. This was very pessimistic.It isn't actually necessary to "behave aggressively" to maintain theability to advance relfrozenxid when a cleanup lock isn't immediatelyavailable (most of the time). The non-aggressive case will now makesure that it isn't safe to advance relfrozenxid (without waiting) usingonly a share lock. It will usually notice that there are no tuples thatneed to be frozen anyway, just like in the aggressive case -- and so itno longer wastes an opportunity to advance relfrozenxid over nothing.(The non-aggressive case still won't wait for a cleanup lock when therereally are tuples on the page that need to be frozen, since that reallywould amount to "behaving aggressively".)VACUUM currently has a tendency to set heap pages to all-visible in thevisibility map before it freezes all of the tuples on the page. Only asubsequent aggressive VACUUM will visit these pages to freeze theirtuples, usually only when the tuple XIDs are much older than thevacuum_freeze_min_age GUC (FreezeLimit cutoff) is supposed to allow.And so non-aggressive VACUUMs are still far less likely to be able toadvance relfrozenxid in practice, even with the enhancements from thiscommit. This remaining issue will be addressed by future work thatoverhauls the criteria for freezing tuples. Once that's in place,almost every VACUUM operation will be able to advance relfrozenxid inpractice.Author: Peter Geoghegan <pg@bowt.ie>Reviewed-By: Andres Freund <andres@anarazel.de>Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>Discussion:https://postgr.es/m/CAH2-Wznp=c=Opj8Z7RMR3G=ec3_JfGYMN_YvmCEjoPCHzWbx0g@mail.gmail.com1 parent4eb2176 commit44fa848
File tree
3 files changed
+514
-296
lines changed- src
- backend/access/heap
- test/isolation
- expected
- specs
3 files changed
+514
-296
lines changed0 commit comments
Comments
(0)