Re: [HACKERS] 9.3beta2: Failure to pg_upgrade

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Jesse Denardo <denaje(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-bugs(at)postgresql(dot)org, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] 9.3beta2: Failure to pg_upgrade
Date: 2013-08-03 02:44:57
Message-ID: 20130803024457.GA23266@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On 2013-08-02 22:25:36 -0400, Alvaro Herrera wrote:
> 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.)

I am suggesting to set them to a greater value than in the old cluster,
computed so it's guaranteed that they are proper page boundaries. Then
the situation described upthread shouldn't occur anymore, right?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Jesse Denardo 2013-08-03 03:20:37 Re: 9.3beta2: Failure to pg_upgrade
Previous Message Alvaro Herrera 2013-08-03 02:25:36 Re: 9.3beta2: Failure to pg_upgrade

Browse pgsql-hackers by date

  From Date Subject
Next Message Satoshi Nagayasu 2013-08-03 03:12:26 Re: [9.4 CF 1]Commitfest ... over!
Previous Message Alvaro Herrera 2013-08-03 02:25:36 Re: 9.3beta2: Failure to pg_upgrade