On Mon, Oct 10, 2022 at 4:46 PM Peter Geoghegan <p...@bowt.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
