Re: heap vacuum & cleanup locks

On Mon, Jun 30, 2014 at 7:55 PM, Greg Stark <stark@mit.edu> wrote:
> On Wed, Nov 2, 2011 at 3:19 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Tue, Jun 7, 2011 at 3:24 PM, Greg Stark <gsstark@mit.edu> wrote:
>>> 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.
>>
>> I wrote a really neat patch to do this today...  and then, as I
>> thought about it some more, I started to think that it's probably
>> unsafe.  Here's the trouble: with this approach, we assume that it's
>> OK to change the contents of the line pointer while holding only an
>> exclusive lock on the buffer.  But there is a good deal of code out
>> there that thinks it's OK to examine a line pointer with only a pin on
>> the buffer (no lock).  You need a content lock to scan the item
>> pointer array, but once you've identified an item of interest, you're
>> entitled to assume that it won't be modified while you hold a buffer
>> pin.  Now, if you've identified a particular tuple as being visible to
>> your scan, then you might think that VACUUM shouldn't be removing it
>> anyway.  But I think that's only true for MVCC scans - for example,
>> what happens under SnapshotNow semantics?
>
> Well now that you've done all that amazing work eliminating
> SnapshotNow ...

Thank you.  :-)

> ... maybe this patch deserves another look? I see
> anti-wraparound vacuums more and more often as database transaction
> velocity increases and vacuum takes longer and longer as database
> sizes increase. Having a faster vacuum that can skip vacuuming pages
> but is still guaranteed to freeze every page is pretty tempting.
>
> Of course the freeze epoch in the header obviating the need for
> freezing is an even more attractive goal but AIUI we're not even sure
> that's going to work and this is a nice easy win.

Well, there's still SnapshotSelf, SnapshotAny, SnapshotDirty, ...

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