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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +