Simon Riggs wrote:
On Fri, 2007-10-12 at 01:24 -0400, Alvaro Herrera wrote:
Yes, I think it is easy to mark the "is for xid wraparound" bit in the
WorkerInfo struct and have the cancel work only if it's off.
However, what I think should happen is that the signal handler for
SIGINT in a worker for xid wraparound should not cancel the current
vacuum. Instead turn it into a no-op, if possible. That way we also
disallow a user from cancelling vacuums for xid wraparound. I think he
can do that with pg_cancel_backend, and it could be dangerous.
I think that is dangerous too because the user may have specifically
turned AV off. That anti-wraparound vacuum might spring up right in a
busy period and start working its way through many tables, all of which
cause massive writes to occur. That's about as close to us causing an
outage as I ever want to see. We need a way through that to allow the
user to realise his predicament and find a good time to VACUUM. I never
want to say to anybody "nothing you can do, just sit and watch, your
production system will be working again in no time. Restart? no that
won't work either."
You are probably right that VACUUM going full-steam is a bad idea in most
situations. Except for anti-wraparound vacuum, cancellation seems the most
reasonable thing to do. Because autovacuum will usually pickup the table in
time again.
The only problem I would see is if someone has an application that does a
lot of schema changes (doesn't sound like a good idea anyway). In that case
they would better issue manual vacuums on such tables.
Best Regards
Michael Paesold
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
