On Mon, Jun 6, 2011 at 12:49 PM, Alvaro Herrera
<alvhe...@commandprompt.com> wrote:
> Excerpts from Robert Haas's message of lun jun 06 08:06:10 -0400 2011:
>
>> But the problem of vacuum stalling out because it can't get the
>> cleanup lock is a very real one.  I've seen at least one customer hit
>> this in production, and it was pretty painful.  Now, granted, you need
>> some bad application design, too: you have to leave a cursor lying
>> around instead of running it to completion and then stopping.  But
>> supposing you do make that mistake, you might hope that it wouldn't
>> cause VACUUM starvation, which is what happens today.  IOW, I'm less
>> worried about whether the cleanup lock is slowing vacuum down than I
>> am about eliminating the pathological cases where an autovacuum
>> workers gets pinned down, stuck waiting for a cleanup lock that never
>> arrives.  Now the table doesn't get vacuumed (bad) and the system as a
>> whole is one AV worker short of what it's supposed to have (also bad).
>
> One of the good things about your proposal is that (AFAICS) you can
> freeze tuples without the cleanup lock, so the antiwraparound cleanup
> would still work.

Yeah, I think that's a major selling point.  VACUUM getting stuck is
Bad.  Anti-wraparound VACUUM getting stuck is Really Bad.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to