From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Michael Paesold <mpaesold(at)gmx(dot)at>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: First steps with 8.3 and autovacuum launcher |
Date: | 2007-10-12 06:17:51 |
Message-ID: | 1192169871.4233.472.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-10-12 06:22:57 | Re: [HACKERS] quote_literal with NULL |
Previous Message | Alvaro Herrera | 2007-10-12 05:24:29 | Re: First steps with 8.3 and autovacuum launcher |