I don't have a source tree handy but iirc we treaty 2^31 values as being in the past and 2^31 values as being in the future.
I've been trying to think how to protect better against the recent vacuum freeze bug. If someone ruins vacuum freeze now and has any wrapped values they'll destroy their possibly recoverable data. It seems to me we shouldn't really need 2^31 values in the future. If vacuum or hot pruning comes across an xid far in the future, say a million xids further into the future than the most recent transaction, then it should signal an error rather than just treat it as being in the future. -- greg On 12 Dec 2013 09:41, "Tom Lane" <t...@sss.pgh.pa.us> wrote: > Gianni Ciolli <gianni.cio...@2ndquadrant.it> writes: > > It seems there is a typo here: > > > http://www.postgresql.org/docs/devel/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND > > where we say that we compare XIDs using arithmetic modulo 2^31, which > > should instead be 2^32 (as it is with uint32, e.g. xid_age). > > [ thinks about that for awhile... ] Yeah, I think you're right. > Patch pushed, thanks! > > regards, tom lane > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
