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: http://www.postgresql.org/mailpref/pgsql-hackers
