Horton

Re: First steps with 8.3 and autovacuum launcher

Simon Riggs <simon@2ndquadrant.com>

View thread View on postgr.es
From: Simon Riggs <simon@2ndquadrant.com>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: 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>, Heikki Linnakangas <heikki@enterprisedb.com>, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2007-10-04T18:40:46Z
Lists: pgsql-hackers 
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.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com