Re: Decoupling antiwraparound autovacuum from special rules around auto cancellation

On Mon, Oct 24, 2022 at 8:43 AM Jeff Davis <pgsql(at)j-davis(dot)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