Zombie thread arise! I was searching for old threads on a specific problem and came across this patch that was dropped due to concerns about SnapshotNow:
On Wed, Nov 2, 2011 at 3:19 PM, Robert Haas <robertmh...@gmail.com> wrote: > 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? Well now that you've done all that amazing work eliminating SnapshotNow 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. > 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 Another idea would be to store the upper 2-4 bits of the oldest xid in the page. That would let you determine whether it's in need of an anti-wraparound vacuum. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
