Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Andreas Joseph Krogh <andreas(at)visena(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)
Date: 2017-09-12 23:54:15
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


* Andreas Joseph Krogh (andreas(at)visena(dot)com) wrote:
> I have to ask; Why not run pg_upgrade on standby, after verifying that it's in
> sync with primary and promoting it to primary if necessary and then making it
> standby again after pg_upgrade is finished?

I don't think that we could be guaranteed that the catalog tables would
be the same on the replica as on the primary if they were actually
created by pg_upgrade.

The catalog tables *must* be identical between the primary and the
replica because they are updated subsequently through WAL replay, not
through SQL commands (which is how pg_upgrade creates them in the first

Perhaps we could have some mode for pg_upgrade where it handles the
update to replicas (with the additional checks that I outlined and using
the methodology discussed for rsync --hard-links), but that would still
require solving the communicate-over-the-network problem between the
primary and the replicas, which is the hard part. Whether it's an
independent utility or something built into pg_upgrade isn't really that
big of a distinction, though it doesn't seem to me like there'd be much
code reuse there.



In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2017-09-12 23:55:33 Re: Faster methods for getting SPI results
Previous Message Tom Lane 2017-09-12 23:52:31 Re: Automatic testing of patches in commit fest