On Sat, 2022-11-26 at 11:00 -0800, Peter Geoghegan wrote:
> > I think that is a good idea.
> > Wouldn't it make sense to trigger that at *half* "autovacuum_freeze_max_age"?
>
> That would be equivalent to what I've done here, provided you also
> double the autovacuum_freeze_max_age setting.
That's exactly what I was trying to debate. Wouldn't it make sense to
trigger VACUUM earlier so that it has a chance of being less heavy?
On the other hand, if there are not sufficiently many modifications
on the table to trigger autovacuum, perhaps it doesn't matter in many
cases.
> I did it this way
> because I believe that it has fewer problems. The approach I took
> makes the general perception that antiwraparound autovacuum are a
> scary thing (really just needed for emergencies) become true, for the
> first time.
>
> We should expect to see very few antiwraparound autovacuums with the
> patch, but when we do see even one it'll be after a less aggressive
> approach was given the opportunity to succeed, but (for whatever
> reason) failed.
Is that really so much less aggressive? Will that autovacuum run want
to process all pages that are not all-frozen? If not, it probably won't
do much good. If yes, it will be just as heavy as an anti-wraparound
autovacuum (except that it won't block other sessions).
> Just seeing any antiwraparound autovacuums will become
> a useful signal of something being amiss in a way that it just isn't
> at the moment. The docs can be updated to talk about antiwraparound
> autovacuum as a thing that you should encounter approximately never.
> This is possible even though the patch isn't invasive at all.
True. On the other hand, it might happen that after this, people start
worrying about normal autovacuum runs because they occasionally experience
a table age autovacuum that is much heavier than the other ones. And
they can no longer tell the reason, because it doesn't show up anywhere.
Yours,
Laurenz Albe
