On Fri, Jul 27, 2012 at 08:29:20AM -0400, Robert Haas wrote:
> >> 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.
> >
> > OK, sorry, I was confused.  You _have_ to run pg_upgrade on the standby
> > --- there are many things we don't preserve, and we need pg_upgrade to
> > move those user file to the right place --- a obvious example is
> > tablespace files.  Database oids aren't even preserved, so the data
> > directory changes.
> These are reasons why you CANNOT run pg_upgrade on the standby, not
> why you HAVE to.  If you run pg_upgrade on the standby and separately
> on the master, you will end up with divergence precisely because of
> those things that aren't preserved.
> Any approach that calls for pg_upgrade to run on the master and
> standby separately is broken.

Basically, you have to run pg_upgrade on the standby so the user data
files are moved properly, then you would need to run a copy script that
would copy over all the non-user files from the master.

Are you worried that the standby, by becoming a master, will write to
the standby old cluster user data files in a way that is inconsistent
from the master?  If so, I think this entire idea can't work.

  Bruce Momjian  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to