Skip site navigation (1) Skip section navigation (2)

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-04-01 19:50:29
Message-ID: 201104011950.p31JoTE15961@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas wrote:
> On Fri, Apr 1, 2011 at 11:18 AM, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2011-04-01 20:09:49
Subject: Re: Bug in autovacuum.c?
Previous:From: Jan WieckDate: 2011-04-01 19:42:06
Subject: Re: Lock problem with autovacuum truncating heap

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group