Skip site navigation (1) Skip section navigation (2)

Re: First steps with 8.3 and autovacuum launcher

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: 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>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, 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-05 12:27:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, 2007-10-04 at 17:33 -0400, Alvaro Herrera wrote:
> Simon Riggs escribió:
> > 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.
> Ok, I think this makes sense.
> I can offer the following patch -- it makes it possible to determine
> whether an autovacuum process is doing analyze or not, by comparing the
> PGPROC of the running WorkerInfo list (the list has at most
> max_autovacuum_workers entries, so this is better than trolling
> ProcGlobal).

Looks OK to me, thanks for noticing I glossed over the bit about how to
tell whether it was an auto-ANALYZE.

  Simon Riggs

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-10-05 14:52:50
Subject: Re: Polymorphic arguments and composite types
Previous:From: Simon RiggsDate: 2007-10-05 12:25:01
Subject: Polymorphic arguments and composite types

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group