Simon Riggs schreef:
On Fri, 2007-10-12 at 11:44 +0200, Michael Paesold wrote:
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.

Yeh, if we do have to do the second emergency anti-wraparound, then that
should be at full speed, since there's nothing else to do at that point.

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.

I can't see a use case for regular DDL as part of an application, on an
otherwise integral table (lots of updates and deletes).
As part of an application there's no use.
As part of an upgrade between 2 different versions of that application there is. And that's exactly the kind of situation where temporary disabling autovacuum could become handy.

Reply via email to