<p dir="ltr">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
beingin the future.<p dir="ltr">I've been trying to think how to protect better against the recent vacuum freeze bug.
Ifsomeone ruins vacuum freeze now and has any wrapped values they'll destroy their possibly recoverable data.<p
dir="ltr">Itseems to me we shouldn't really need 2^31 values in the future. If vacuum or hot pruning comes across an
xidfar in the future, say a million xids further into the future than the most recent transaction, then it should
signalan error rather than just treat it as being in the future.<p dir="ltr">-- <br /> greg<div class="gmail_quote">On
12Dec 2013 09:41, "Tom Lane" <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br
type="attribution"/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">Gianni Ciolli <<a
href="mailto:gianni.ciolli@2ndquadrant.it">gianni.ciolli@2ndquadrant.it</a>>writes:<br /> > It seems there is a
typohere:<br /> > <a
href="http://www.postgresql.org/docs/devel/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND"
target="_blank">http://www.postgresql.org/docs/devel/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND</a><br/> >
wherewe say that we compare XIDs using arithmetic modulo 2^31, which<br /> > should instead be 2^32 (as it is with
uint32,e.g. xid_age).<br /><br /> [ thinks about that for awhile... ] Yeah, I think you're right.<br /> Patch pushed,
thanks!<br/><br /> regards, tom lane<br /><br /><br /> --<br /> Sent via pgsql-hackers mailing
list(<a href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br /> To make changes to your
subscription:<br/><a href="http://www.postgresql.org/mailpref/pgsql-hackers"
target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/></blockquote></div>