Re: 9.3beta2: Failure to pg_upgrade

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