Re: Using pg_upgrade on log-shipping standby servers

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Using pg_upgrade on log-shipping standby servers
Date: 2012-07-18 13:36:51
Message-ID: CA+TgmobaxuWuMe10NEDkFpbAMknGa8Za0vUcFACcsAPTEVTctA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 17, 2012 at 6:02 PM, Bruce Momjian <bruce(at)momjian(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit kapila 2012-07-18 13:47:50 Patch for option in pg_resetxlog for restore from WAL files
Previous Message Robert Haas 2012-07-18 12:40:57 Re: CompactCheckpointerRequestQueue versus pad bytes