Re: Using pg_upgrade on log-shipping standby servers

On Mon, Jul 16, 2012 at 5:29 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Tue, 2012-07-10 at 11:50 -0400, Bruce Momjian wrote:
>> I don't think we can assume that because pg_upgrade was run on the
>> master and standby that they are binary identical, can we? Technically
>> the user file are identical, but the system catalogs and WAL might be
>> different, hence my suggestion to run rsync before allowing the standby
>> to rejoin the primary.
>
> Do you have plans to change that in the future?
>
> If we know that the user data files are identical between primary and
> replica, it would be nice if we could provide a robust way to avoid
> copying them.

How about this alternative that may sound crazy, but would lend itself
to some unification in archiving:

Could pg_upgrade emit WAL segment(s) to provide continuity of a
timeline? So something like:

* Take down the writable primary for pg_upgrade
* Some WAL is emitted and possibly archived
* The old version, when reaching the special pg_upgrade WAL, could
exit or report its situation having paused replay (as clearly, it
cannot proceed). Unsure.
* Start up a new version of postgres on the same cluster at that
point, which plays the upgrade-WAL.

I see this being pretty mechanically intensive, but right now my hands
are completely tied as to achieving total continuity of my archives,
costing a base-backup's worth of risk window upon upgrade.

--
fdr