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

Re: First steps with 8.3 and autovacuum launcher

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, Simon Riggs <simon(at)2ndquadrant(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-04 15:45:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Gregory Stark wrote:
> "Alvaro Herrera" <alvherre(at)commandprompt(dot)com> writes:
>> Hmm, it looks like the race condition Heikki mentioned is the culprit.
>> We need a way to stop future analyzes from starting.  Back to the
>> drawing board ...
> 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 idea would be to make no changes to the relation_openrv call,
but have autovacuum periodically check if anyone's blocked waiting on
its locks, and commit suicide (or set cost delay to zero) if so.

  Heikki Linnakangas

In response to

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2007-10-04 15:52:50
Subject: tsearch2 wrapper
Previous:From: Josh BerkusDate: 2007-10-04 15:43:24
Subject: Re: What does 'elapsed' exact means in PostgreSQL Log Statistics

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