* Andres Freund (andres@2ndquadrant.com) wrote:
> On 2015-01-22 20:54:47 -0500, Stephen Frost wrote:
> > * Bruce Momjian (bruce@momjian.us) wrote:
> > > On Fri, Jan 23, 2015 at 01:19:33AM +0100, Andres Freund wrote:
> > > > Or do you - as the text edited in your patch, but not the quote above -
> > > > mean to run pg_upgrade just on the primary and then rsync?
> > >
> > > No, I was going to run it on both, then rsync.
> >
> > I'm pretty sure this is all a lot easier than you believe it to be. If
> > you want to recreate what pg_upgrade does to a cluster then the simplest
> > thing to do is rsync before removing any of the hard links. rsync will
> > simply recreate the same hard link tree that pg_upgrade created when it
> > ran, and update files which were actually changed (the catalog tables).
>
> I don't understand why that'd be better than simply fixing (yes, that's
> imo the correct term) pg_upgrade to retain relfilenodes across the
> upgrade. Afaics there's no conflict risk and it'd make the clusters much
> more similar, which would be good; independent of rsyncing standbys.
That's an entirely orthogonal discussion from the original one though,
no? That wouldn't actually help with what Bruce is trying to do, which
is to duplicate the results of the pg_upgrade from the master over to
the standby. Even if the relfilenodes were the same across the upgrade,
I don't think it'd be a good idea to run pg_upgrade on the standby and
hope the results match close enough to the master that you can trust
updates to the catalog tables on the standby from the master going
forward to work..
Trying to pg_upgrade both the master and the standby, to me at least,
seems like an even *worse* approach than trusting rsync with -H and
--size-only..
Thanks,
Stephen