Re: pg_upgrade cleanup - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade cleanup
Date
Msg-id 20150518145842.GA28626@momjian.us
Whole thread Raw
In response to Re: pg_upgrade cleanup  (Noah Misch <noah@leadboat.com>)
Responses Re: pg_upgrade cleanup
List pgsql-hackers
On Sat, May 16, 2015 at 12:21:12PM -0400, Noah Misch wrote:
> The rest of this change is opaque to me.  "More consistent" with what?  The
> old use of the "tli" variable sure looked like a bug, considering the variable
> was never set to anything but zero.  What is the anticipated behavior change?

The fact you saw the bug helps in another way.  I was confused why we
had not gotten reports about incorrect timeline restoration in previous
versions of pg_upgrade.  It turns out that through 9.2, we always used a
timeline of 1:
"\"%s/pg_resetxlog\" -l 1,%u,%u \"%s\"", new_cluster.bindir,                        ^

In 9.3 we added code to restore the timeline, but the code that read the
9.2 pg_controldata was buggy, so it tried to restore a timeline of 0,
which was ignored because the timeline can't be decreased with
pg_resetxlog.  Only in 9.4 was the timeline properly restored, leading
to the missing history file error.

This confirms that setting the timeline to 1 unconditionally, as I did
on Friday, is the right fix, and I have added a C comment so we will
remember _why_ this has to be the case.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Uriy Zhuravlev
Date:
Subject: Re: WIP: Enhanced ALTER OPERATOR
Next
From: Alexander Korotkov
Date:
Subject: Re: WIP: Enhanced ALTER OPERATOR