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 http://www.amazon.com/gp/registry/5ZYLFMCVHXC
Maybe there's lots of data loss but the records of data loss are also lost.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2007-10-01 22:58:01|
|Subject: Re: pgsql: Use BIO functions to avoid passing FILE * pointers to OpenSSL |
|Previous:||From: Tom Lane||Date: 2007-10-01 22:53:40|
|Subject: Re: First steps with 8.3 and autovacuum launcher |