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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
