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
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

Reply via email to