Re: First steps with 8.3 and autovacuum launcher
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndquadrant.com>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Michael Paesold <mpaesold@gmx.at>, Heikki Linnakangas <heikki@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>, Gregory Stark <stark@enterprisedb.com>, Guillaume Smet <guillaume.smet@gmail.com>, "Matthew T. O'Connor" <matthew@zeut.net>, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2007-10-12T06:17:51Z
Lists: pgsql-hackers
On Fri, 2007-10-12 at 01:24 -0400, Alvaro Herrera wrote: > Michael Paesold escribió: > > Simon Riggs wrote: > > > 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? > > 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." -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com