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

Re: First steps with 8.3 and autovacuum launcher

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: 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>, 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-04 16:55:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Gregory Stark escribió:
> "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 crazy idea is to have some sort of "blacklist" of tables in
shared memory.  Any autovacuum process would skip those tables.
My idea is that a would-be locker automatically puts the table in the
blacklist, then kill autovacs, then press on.

My idea is to accompany the relid with the Xid of the locker
transaction, so the worker checks whether the transaction is still
running, and removes the item from the blacklist if not.

(The only problem then is figuring out how large a black list to have,
and how to evict items when it is full and somebody else wants to
blacklist another table.  For pg_dump it is more than enough to have
MaxBackends, since there is always at most one transaction, but I
wouldn't be surprised if I'm overlooking something.)

Alvaro Herrera                      
The PostgreSQL Company - Command Prompt, Inc.

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2007-10-04 17:30:55
Subject: Re: First steps with 8.3 and autovacuum launcher
Previous:From: Kris JurkaDate: 2007-10-04 16:40:59
Subject: Re: Not *quite* there on ecpg fixes

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