On Mon, Oct 24, 2022 at 8:43 AM Jeff Davis <pg...@j-davis.com> wrote: > > Even if regular/early autovacuum had just one > > opportunity to run to completion, we'd already be much better off. > > By "opportunity", you mean that, regardless of configuration, the > cancellable autovacuum would at least start; though it still might be > cancelled by DDL. Right?
Yes, exactly. It might be difficult as a practical matter to make sure that we *reliably* give autovacuum.c the opportunity to launch a "standard" autovacuum tasked with advancing relfrozenxid (just after autovacuum_freeze_max_age is first crossed) before the point that a scary antiwraparound autovacuum is launched. So we might end up giving it more XID slack than it's likely to ever need (say by only launching a traditional antiwraparound autovacuum against tables that attain an age that is twice the value of autovacuum_freeze_max_age). These are all just details, though -- the important principle is that we try our utmost to give the less disruptive strategy a chance to succeed before concluding that it has failed, and then "escalating" to a traditional antiwraparound autovacuum. > > These are all fundamentally the same operations with the > > same urgency to users, though. We'd only need to describe the > > *criteria* that *triggered* the autovacuum in our autovacuum log > > report > > Hmm... I'm worried that could be a bit confusing depending on how it's > done. Let's be clear that it was merely the triggering criteria and > doesn't necessarily represent the work that is being done. Maybe it could be broken out into a separate "autovacuum triggered by: " line, seen only in the autovacuum log instrumentation (and not in the similar report output by a manual VACUUM VERBOSE). When we still end up "escalating" to an antiwraparound autovacuum, the "triggered by:" line would match whatever we'd show in the benign the non-cancellable-but-must-advance-relfrozenxid autovacuum case. The difference would be that we'd now be reporting on a different operation entirely (not just a regular autovacuum, a scary antiwraparound autovacuum). (Again, even these distinctions wouldn't be meaningful to vacuumlazy.c itself -- it would just need to handle the details around logging in a way that gave users the right idea. There wouldn't be any special discrete aggressive mode of operation anymore, assuming my big patch set gets into Postgres 16 too.) > There are enough cases that it would be good to start a document and > outline the end behavior that your patch series is designed to > accomplish. In other words, a before/after of the interesting cases. That's on my TODO list. Mostly it's an independent thing to this (antiwraparound) autovacuum stuff, despite the fact that both projects share the same underlying philosophy. -- Peter Geoghegan
