On Mon, Jun 30, 2014 at 7:55 PM, Greg Stark <st...@mit.edu> wrote: > 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 ...
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
