"Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> Hm, I wonder if you could just notice that xmin is younger than OldestXmin.
>
> You can see that at the newer tuple, but the problem is to propagate the
> knowledge back to the older tuple(s). Or were you suggesting that we
> treat the newer tuple as RECENTLY_DEAD instead of DEAD? That seems a
> step backwards in space-reclamation ability. It'd be hard to implement
> in any case, because one of the problem cases is where VACUUM has
> already recycled the DEAD tuple before visiting the RECENTLY_DEAD tuple
> that chains to it.
I think I was suggesting treating the newer tuple as RECENTLY_DEAD. Ie, not
vacuuming a tuple if either xmin or xmax is younger than OldestXmin. It's a
step backwards in space-reclamation but really, how often can it happen?
But I'm not entirely sure that's enough really. Any number of old transactions
could come along and update the head of the tuple chain, setting both xmin and
xmax to old values. I guess only the one tuple immediately following the
RECENTLY_DEAD tuple would have the young xmin. That doesn't really help you
identify the later DEAD tuples.
Breaking the chain up into pieces seems weird. It seems like it's obviously
bogus and only works because we're sure the tuples are dead anyways so it
doesn't really matter what we do with them. If we're not sure they're dead it
seems like the right thing to do is either to keep the whole chain or to
relink the chain after removing the dead intervening tuples.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
