On Wed, Mar 23, 2022 at 2:03 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > Yeah, I found it confusing that DISABLE_PAGE_SKIPPING doesn't disable > all page skipping, so 3414099c turned out to be not enough.
The proposed change to DISABLE_PAGE_SKIPPING is partly driven by that, and partly driven by a similar concern about aggressive VACUUM. It seems worth emphasizing the idea that an aggressive VACUUM is now just the same as any other VACUUM except for one detail: we're guaranteed to advance relfrozenxid to a value >= FreezeLimit at the end. The non-aggressive case has the choice to do things that make that impossible. But there are only two places where this can happen now: 1. Non-aggressive VACUUMs might decide to skip some all-visible pages in the new lazy_scan_skip() helper routine for skipping with the VM (see v11-0002-*). 2. A non-aggressive VACUUM can *always* decide to ratchet back its target relfrozenxid in lazy_scan_noprune, to avoid waiting for a cleanup lock -- a final value from before FreezeLimit is usually still pretty good. The first scenario is the only one where it becomes impossible for non-aggressive VACUUM to be able to advance relfrozenxid (with v11-0001-* in place) by any amount. Even that's a choice, made by weighing costs against benefits. There is no behavioral change in v11-0002-* (we're still using the old SKIP_PAGES_THRESHOLD strategy), but the lazy_scan_skip() helper routine could fairly easily be taught a lot more about the downside of skipping all-visible pages (namely how that makes it impossible to advance relfrozenxid). Maybe it's worth skipping all-visible pages (there are lots of them and age(relfrozenxid) is still low), and maybe it isn't worth it. We should get to decide, without implementation details making relfrozenxid advancement unsafe. It would be great if you could take a look v11-0002-*, Robert. Does it make sense to you? Thanks -- Peter Geoghegan