Re: heap vacuum & cleanup locks

On Tue, Jun 7, 2011 at 3:24 PM, Greg Stark <gsstark(at)mit(dot)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? But then then on third
thought, if you've also got an MVCC snapshot taken before the start of
the SnapshotNow scan, you are probably OK, because your advertised
xmin should prevent anyone from removing anything anyway, so how do
you actually provoke a failure?

Anyway, I'm attaching the patch, in case anyone has any ideas on where
to go with this.

> I'm really wishing we had more bits in the vm. It looks like we could use:
>  - contains not-all-visible tuples
>  - contains not-frozen xids
>  - in need of compaction
>
> I'm sure we could find a use for one more page-level vm bit too.

We've got plenty of room for more page-level bits, if we need them.

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