On Thu, 2007-10-11 at 21:59 +0200, Michael Paesold wrote: > So in case a vacuum is needed for that very reason, the vacuum should *not* > be canceled, of course. So we don't really need the information, whether > the AV worker is doing VACUUM or ANALYZE, but whether it is critical > against xid wrap-around. Could that be done as easily as in Alvaro's patch > for distinguishing vacuum/analyze? Alvaro?
Well, I did think about this. We probably want to preserve the ability of an autovacuum to be manually cancelled. So the only way to do this is by letting the would-be canceller know that they shouldn't cancel that one by marking the autovacuum to show it is a "compulsory" one. We could change the field on PGPROC from a boolean isAutovacuum to a status flag, so we have bit flags for IS_AUTOVACUUM and IS_WRAPAROUND_AVOIDANCE. I think that's overkill personally, but you might argue me round. > The other thing I am wondering about is, whether it would be a safer > approach to let the DBA decide whether to cancel AV vacuums or just disable > cost-delay, as Heikki suggested. There might be valid work-loads for both > options... Cancelling the VACUUM hurts nobody, and allows the DDL to be run now, not later when the database server gets round to it. Speeding up a delayed vacuum will hurt everybody. A big VACUUM can last hours, even at full speed and that is a big beast to let loose during prime time. BTW I took the liberty of starting a new thread on this. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
