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