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

Re: Autovacuum cancellation

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Autovacuum cancellation
Date: 2007-10-27 22:22:40
Message-ID: 1193523760.4242.628.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackerspgsql-patches
On Fri, 2007-10-26 at 10:32 +0100, Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
> > /*
> >  * Look for a blocking autovacuum. There will only ever
> >  * be one, since the autovacuum workers are careful
> >  * not to operate concurrently on the same table. 
> >  */
> 
> I think that's a bit unaccurate. You could have multiple autovacuum
> workers operating on different tables participating in a deadlock. The
> reason that can't happen is that autovacuum never holds a lock while
> waiting for another.

I wrote that code comment; as you say it is true only when there are at
least 4 processes in the lock graph where 2+ normal backends are
deadlocking and there are 2+ autovacuums holding existing locks. The
comment should have said "If blocking is caused by an autovacuum process
then ... (there will)".

The blocking_autovacuum_proc doesn't react unless there are no hard
deadlocks, so the code works.

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


In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2007-10-27 22:31:02
Subject: Re: Autovacuum cancellation
Previous:From: Simon RiggsDate: 2007-10-27 22:15:12
Subject: Re: Autovacuum cancellation

pgsql-committers by date

Next:From: Simon RiggsDate: 2007-10-27 22:31:02
Subject: Re: Autovacuum cancellation
Previous:From: User KostasDate: 2007-10-27 22:18:08
Subject: pgtreelib - pgtreelib:

pgsql-patches by date

Next:From: Simon RiggsDate: 2007-10-27 22:31:02
Subject: Re: Autovacuum cancellation
Previous:From: Simon RiggsDate: 2007-10-27 22:15:12
Subject: Re: Autovacuum cancellation

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