Horton

Re: First steps with 8.3 and autovacuum launcher

Alvaro Herrera <alvherre@commandprompt.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Simon Riggs <simon@2ndquadrant.com>, "Matthew T. O'Connor" <matthew@zeut.net>, Heikki Linnakangas <heikki@enterprisedb.com>, Gregory Stark <stark@enterprisedb.com>, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>, Guillaume Smet <guillaume.smet@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2007-10-01T22:56:55Z
Lists: pgsql-hackers 
Tom Lane escribió:
> Simon Riggs <simon@2ndquadrant.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                  http://www.amazon.com/gp/registry/5ZYLFMCVHXC
Maybe there's lots of data loss but the records of data loss are also lost.
(Lincoln Yeoh)