On Mon, Oct 24, 2022 at 9:00 AM Peter Geoghegan <p...@bowt.ie> wrote: > 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).
Attached WIP patch invents the idea of a regular autovacuum that is tasked with advancing relfrozenxid -- which is really just another trigger criteria, reported on in the server log in its autovacuum reports. Of course we retain the idea of antiwraparound autovacuums. The only difference is that they are triggered when table age has advanced by twice the usual amount, which is presumably only possible because a regular autovacuum couldn't start or couldn't complete in time (most likely due to continually being auto-cancelled). As I said before, I think that the most important thing is to give regular autovacuuming a chance to succeed. The exact approach taken has a relatively large amount of slack, but that probably isn't needed. So the new antiwraparound cutoffs were chosen because they're easy to understand and remember, which is fairly arbitrary. Adding this to the upcoming CF. -- Peter Geoghegan
v1-0001-Add-table-age-trigger-concept-to-autovacuum.patch
Description: Binary data