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
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2007-10-04 21:33:43|
|Subject: 8.4 TODO item: make src/port support libpq and ecpg directly|
|Previous:||From: Tom Lane||Date: 2007-10-04 21:08:29|
|Subject: Re: Connection Pools and DISCARD ALL |