Re: heap vacuum & cleanup locks

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: heap vacuum & cleanup locks
Date: 2011-06-06 16:49:20
Message-ID: 1307378837-sup-5525@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-06-06 16:49:46 Re: Postmaster holding unlinked files for pg_largeobject table
Previous Message Tom Lane 2011-06-06 16:47:44 Re: WALInsertLock tuning