Re: autovacuum_freeze_max_age reloption seems broken

On Mon, Oct 10, 2022 at 4:46 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> There is no reason to think that the user will also (say) set the
> autovacuum_freeze_table_age reloption separately (not to be confused
> with the vacuum_freeze_table_age GUC!). We'll usually just work off
> the GUC (I mean why wouldn't we?). I don't see why vacuumlazy.c
> doesn't just force aggressive mode whenever it sees an antiwraparound
> autovacuum, no matter what.

Actually, even forcing every antiwraparound autovacuum to use
aggressive mode isn't enough to stop autovacuum.c from spinning. It
might be a good start, but it still leaves the freeze_min_age issue.

The only way that autovacuum.c is going to be satisfied and back off
with launching antiwraparound autovacuums is if relfrozenxid is
advanced, and advanced by a significant amount. But what if the
autovacuum_freeze_max_age reloption happens to have been set to
something that's significantly less than the value of the
vacuum_freeze_min_age GUC (or the autovacuum_freeze_min_age reloption,
even)? Most of the time we can rely on vacuum_set_xid_limits() making
sure that the FreezeLimit cutoff (cutoff that determines which XID
we'll freeze) isn't unreasonably old relative to other cutoffs. But
that won't work if we're forcing an aggressive VACUUM in vacuumlazy.c.

I suppose that this separate freeze_min_age issue could be fixed by
teaching autovacuum.c's table_recheck_autovac() function to set
freeze_min_age to something less than the current value of reloptions
like autovacuum_freeze_min_age and autovacuum_freeze_table_age for the
same table (when either of the table-level reloptions happened to be
set). In other words, autovacuum.c could be taught to make sure that
these reloption-based cutoffs have sane values relative to each other
by applying roughly the same approach taken in vacuum_set_xid_limits()
for the GUCs.

--
Peter Geoghegan