"Tom Lane" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
