Re: First steps with 8.3 and autovacuum launcher

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