Re: [BUGS] 9.3beta2: Failure to pg_upgrade

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: [BUGS] 9.3beta2: Failure to pg_upgrade
Дата
Msg-id 20130803022536.GX5669@eldon.alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: [BUGS] 9.3beta2: Failure to pg_upgrade  (Andres Freund <andres@2ndquadrant.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [BUGS] 9.3beta2: Failure to pg_upgrade
Следующее
От: Satoshi Nagayasu
Дата:
Сообщение: Re: [9.4 CF 1]Commitfest ... over!