Re: Bug in autovacuum.c?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug in autovacuum.c?
Date: 2011-03-31 20:16:55
Message-ID: 201103312016.p2VKGtU23848@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
> On Thu, Mar 31, 2011 at 2:59 PM, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-03-31 20:18:10 Re: Problem with pg_upgrade?
Previous Message Peter Eisentraut 2011-03-31 20:10:47 Re: Windows build issues