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
