Re: Using pg_upgrade on log-shipping standby servers - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Using pg_upgrade on log-shipping standby servers
Date
Msg-id CA+TgmobaxuWuMe10NEDkFpbAMknGa8Za0vUcFACcsAPTEVTctA@mail.gmail.com
Whole thread Raw
In response to Re: Using pg_upgrade on log-shipping standby servers  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Using pg_upgrade on log-shipping standby servers  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Tue, Jul 17, 2012 at 6:02 PM, Bruce Momjian <bruce@momjian.us> wrote:
> However, I have two ideas.  First, I don't know _why_ the
> primary/standby would be any different after pg_upgrade, so I added the
> documentation mention because I couldn't _guarantee_ they were the same.
> Actually, if people can test this, we might be able to say this is safe.
>
> Second, the user files (large) are certainly identical, it is only the
> system tables (small) that _might_ be different, so rsync'ing just those
> would add the guarantee, but I know of no easy way to rsync just the
> system tables.

I'm scratching my head in confusion here.  After pg_upgrade, the
master is a completely new cluster.  The system catalog contents are
completely different, and so are things like the database system
identifier and the WAL position - yeah, the latter is approximately
the same, but almost doesn't count except in horseshoes.  Obviously
any attempt to replay WAL from the new cluster on the old cluster is
doomed to failure, at least unless we do a bunch more engineering here
that hasn't really been thought about yet.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: CompactCheckpointerRequestQueue versus pad bytes
Next
From: Amit kapila
Date:
Subject: Patch for option in pg_resetxlog for restore from WAL files