Re: First steps with 8.3 and autovacuum launcher

Simon Riggs wrote:
> After some thought, you and Michael have persuaded me that there is
> cause to do this for VACUUM as well, but just autovacuum, I think. That
> also makes the patch simpler, since we don't need to delve inside the av
> worker to see what it is doing.
> 
> Alvaro: That means we can just skip your patch altogether, or at least
> we can discuss them separately now.
...
>> The only danger I can see is that the autovacuum is always killed and
>> never gets to finish, leading to degrading performance at first and
>> shutdown to prevent xid wraparound at the extreme. Doesn't seem likely
>> under normal circumstances, though. 
> 
> Yeh agreed. Table locks aren't that common, so I think we are safe for
> 100s of millions of transactions. The user has log messages to warn of
> that, so I think we're good.

Hmm, I am not sure we are there, yet. Autovacuum does take extra care to 
vacuum tables nearing xid wrap-around, right? It even does so when 
autovacuum is disabled in the configuration.

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?

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

Btw., I am grateful you took up the work here, Simon.

Best Regards
Michael Paesold