On Sat, Nov 26, 2022 at 9:58 AM Laurenz Albe <laurenz.a...@cybertec.at> wrote: > The target is a table that receives no DML at all, right?
Sort of, but not really. The target is a table that doesn't get vacuumed for any other reason -- I don't make any claims beyond that one. It seems a little too optimistic to suppose that such a table really didn't need any vacuuming to deal with bloat just because autovacuum.c didn't seem to think that it did. > 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. 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. 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. -- Peter Geoghegan
