On Tue, Jun 7, 2011 at 3:24 PM, Greg Stark <gsst...@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? 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
vacuum-unstick-v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
