On Thu, 2007-10-04 at 19:40 +0100, Simon Riggs wrote:
> On Thu, 2007-10-04 at 14:33 -0400, Alvaro Herrera wrote:
> > Tom Lane escribió:
> > > Alvaro Herrera <alvherre@commandprompt.com> writes:
> > > > Gregory Stark escribi:
> > > >> A crazy idea I just had -- what if you roll this into the deadlock check? So
> > > >> after waiting on the lock for 1s it wakes up, finds that the holder it's
> > > >> waiting on is an autovacuum process and cancels it instead of finding no
> > > >> deadlock.
> > >
> > > > Another crazy idea is to have some sort of "blacklist" of tables in
> > > > shared memory. Any autovacuum process would skip those tables.
> > >
> > > The deadlock check idea sounds promising to me, not least because it
> > > avoids adding any cycles in performance-critical paths. I'm not certain
> > > how easy it'd be to fold the idea into the checker though. That
> > > logic is pretty complicated :-( and I'm not sure that it makes a
> > > consistent effort to visit every possible blocker.
> >
> > The idea sounds interesting, but I am not at all sure how to fit it in
> > the deadlock code.
> >
> > I am totally uninclined to mess with this stuff.
>
> I'll look at it, if Greg isn't already doing so.
Seems like we don't need to mess with the deadlock checker itself.
We can rely on the process at the head of the lock wait queue to sort
this out for us. So all we need do is look at the isAutovacuum flag on
the process that is holding the lock we're waiting on. If it isn't an
autoANALYZE we can carry on with the main deadlock check. We just need a
new kind of deadlock state to handle this, then let ProcSleep send
SIGINT to the autoANALYZE and then go back to sleep, waiting to be
reawoken when the auotANALYZE aborts.
So it looks do-able without major horrors.
-- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com