Re: [BUGS] 9.3beta2: Failure to pg_upgrade - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [BUGS] 9.3beta2: Failure to pg_upgrade
Date
Msg-id 20130803022536.GX5669@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: [BUGS] 9.3beta2: Failure to pg_upgrade  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: [BUGS] 9.3beta2: Failure to pg_upgrade  (Andres Freund <andres@2ndquadrant.com>)
Re: [BUGS] 9.3beta2: Failure to pg_upgrade  (Jesse Denardo <denaje@gmail.com>)
List pgsql-hackers
Andres Freund escribió:
> On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote:
> > Alvaro Herrera escribió:
> > 
> > > As it turns out, I have a patched slru.c that adds a new function to
> > > verify whether a page exists on disk.  I created this for the commit
> > > timestamp module, for the BDR branch, but I think it's what we need
> > > here.
> > 
> > Here's a patch that should fix the problem.  Jesse, if you're able to
> > test it, please give it a run and let me know if it works for you.  I
> > was able to upgrade an installation containing a problem that should
> > reproduce yours.
> 
> Wouldn't it be easier to make pg_upgrade fudge pg_control to have a safe
> NextMultiXactId/Offset using pg_resetxlog?

I don't understand.  pg_upgrade already fudges pg_control to have a safe
next multi, namely the same value used by the old cluster.  The reason
to preserve this value is that we must ensure no older value is
consulted in pg_multixact: those might be present in tuples that were
locked in the old cluster.  (To be precise, this is the value to set as
oldest multi, not next multi.  But of course, the next multi must be
greater than that one.)

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [BUGS] 9.3beta2: Failure to pg_upgrade
Next
From: Satoshi Nagayasu
Date:
Subject: Re: [9.4 CF 1]Commitfest ... over!