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

From Bruce Momjian
Subject Re: Using pg_upgrade on log-shipping standby servers
Date
Msg-id 20120726181722.GL21271@momjian.us
Whole thread Raw
In response to Re: Using pg_upgrade on log-shipping standby servers  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Using pg_upgrade on log-shipping standby servers  (Jeff Davis <pgsql@j-davis.com>)
Re: Using pg_upgrade on log-shipping standby servers  (Bruce Momjian <bruce@momjian.us>)
Re: Using pg_upgrade on log-shipping standby servers  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Jul 26, 2012 at 01:24:19PM -0400, Robert Haas wrote:
> On Thu, Jul 26, 2012 at 12:06 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > I don't see the "don't modify the user files" behavior changing anytime
> > soon, and it is documented, so I feel pretty confident that those files
> > were not modified on the primary or standby cluster, and are hence the
> > same, or at least as "the same" as they were when they were running the
> > older major version of Postgres.
> >
> > Is that sufficient?
> 
> Well, at the very least, you need to guarantee that the standby is
> caught up - i.e. that it replayed all the WAL records that were
> generated on the master before it was shut down for the final time.  I
> don't think that telling the user that they must be sure to do that is
> sufficient - you need some kind of built-in safeguard that will
> complain loudly if it's not the case.

Yes, that would be a problem because the WAL records are deleted by
pg_upgrade.   Does a shutdown of the standby not already replay all WAL
logs?  We could also just require them to just start the standby in
master mode and shut it down.  The problem with that is it might run
things like autovacuum.

I was originally thinking that we would require users to run pg_upgrade
on the standby, where you need to first switch into master mode.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Covering Indexes
Next
From: Jeff Davis
Date:
Subject: Re: Using pg_upgrade on log-shipping standby servers