Robert Haas wrote:
> On Thu, Mar 31, 2011 at 2:59 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > Bruce Momjian wrote:
> >> > Yeah, I think this change would have the effect of moving the freeze
> >> > limit by one (or two?) counts. ?Given the moving nature of values
> >> > returned by ReadNewTransactionId this would probably have no practical
> >> > effect. ?Still, the code as is seems more natural to me (Tom wrote this
> >> > bit IIRC, not me).
> >>
> >> I am now thinking the code is correct --- it maps values from 0 to
> >> FirstNormalTransactionId into the top of the (unsigned) xid range.
> >> Unless someone objects, I will add a C comment about this behavior so
> >> future readers are not confused.
> >
> > OK, now I think it is wrong. ? :-)
> >
> > The effect is to map max xid + 1 to max xid -
> > FirstNormalTransactionId(3) + 1, which makes the xid look like it is
> > going backwards, less than max xid --- not good.
>
> The XID space is *circular*.
Right but you would think that as the xid moves forward, the caculation
of how far back to vacuum should move only forward. In this case,
incrementing the xid by one would cause the vacuum horizon to move
backward by two.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
