Horton

Re: heap vacuum & cleanup locks

Simon Riggs <simon@2ndquadrant.com>

View thread
From: Simon Riggs <simon@2ndQuadrant.com>
To: Greg Stark <gsstark@mit.edu>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Jim Nasby <jim@nasby.net>, Robert Haas <robertmhaas@gmail.com>, Itagaki Takahiro <itagaki.takahiro@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-06-07T19:43:58Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make VACUUM avoid waiting for a cleanup lock, where possible.

On Tue, Jun 7, 2011 at 8:24 PM, Greg Stark <gsstark@mit.edu> wrote:
> On Mon, Jun 6, 2011 at 11:30 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> But I think you've hit the important point here. The problem is not
>> whether VACUUM waits for the pin, its that the pins can be held for
>> extended periods.
>
> Yes
>
>> It makes more sense to try to limit pin hold times than it does to
>> come up with pin avoidance techniques.
>
> Well it's super-exclusive-vacuum-lock avoidance techniques. Why
> shouldn't it make more sense to try to reduce the frequency and impact
> of the single-purpose outlier in a non-critical-path instead of
> burdening every other data reader with extra overhead?
>
> I think Robert's plan is exactly right though I would phrase it
> differently. We should get the exclusive lock, freeze/kill any xids
> and line pointers, then if the pin-count is 1 do the compaction.

Would that also be possible during recovery?

A similar problem exists with Hot Standby, so I'm worried fixing just
VACUUMs would be a kluge.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services