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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: First steps with 8.3 and autovacuum launcher
Date: 2007-10-01 22:56:55
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
Tom Lane escribió:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > We should not allow VACUUM to be concurrent with either CREATE INDEX or
> > ANALYZE, but then thats not the problem here anyway.
> I can't believe anyone is short-sighted enough to think that.
> The problem here is that autovac takes locks that block foreground
> sessions that want exclusive locks.  We've always known this and always
> ignored it, but if autovac is on by default then it's going to be in
> people's faces a lot more than it was before, and they won't be happy.
> If you insist on crafting a solution that only fixes this problem for
> pg_restore's narrow usage, you'll be back revisiting it before beta1
> has been out a month.

So you say we should make any job that needs an exclusive lock on a
table to be able to cancel a running autovac job?  If we did that,
autovac couldn't do very much of anything.

If that's not what you're saying, I'm afraid I'm not getting it.

Alvaro Herrera        
Maybe there's lots of data loss but the records of data loss are also lost.
(Lincoln Yeoh)

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2007-10-01 22:58:01
Subject: Re: pgsql: Use BIO functions to avoid passing FILE * pointers to OpenSSL
Previous:From: Tom LaneDate: 2007-10-01 22:53:40
Subject: Re: First steps with 8.3 and autovacuum launcher

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