On Mon, Jun 6, 2011 at 12:49 PM, Alvaro Herrera
<alvherre@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
