Re: Bug in autovacuum.c?

Robert Haas wrote:
> On Fri, Apr 1, 2011 at 11:18 AM, Bruce Momjian <bruce@momjian.us> wrote:
> > Robert Haas wrote:
> >> Oh, quite right. ?Sorry I missed that. ?I suppose if we wanted to fix
> >> this for real, we'd want to get:
> >>
> >> 105->5
> >> 104->4
> >> 103->3
> >> 102->max_xid
> >> 101->max_xid-1
> >> 100->max_xid-2
> >> 99->max_xid-3
> >> 98->max_xid-4
> >>
> >> But it doesn't seem worth getting excited about.
> >
> > I think (?) the problem with that is the every time you wrap around you
> > get more out of sync. ?:-O
> 
> It's not clear to me that it matters a bit, though.

To do the right thing every computation that passes over the xid
wraparound bounary should subtract FirstNormalTransactionId, not just
those that fall in the boundry.  That would prevent the value from going
backward and still allow the mapping you liked;  it isn't worth it, but
that is the right answer.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +