On Thu, Jul 26, 2012 at 2:26 PM, Jeff Davis <pg...@j-davis.com> wrote: >> 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. > > That sounds a little strange to me. If the original master has generated > WAL that the original standby hasn't seen yet, then this doesn't help > because the two systems would be diverged, and you'd need a new base > backup anyway. And if they have played exactly the same WAL, what does > this accomplish?
This whole approach of coordinating precise content of a standby cluster to run pg_upgrade and then resynchronizing with a also-pg-upgraded primary at a precise WAL position that does not increment to complete the upgrade does not excite me in the slightest: I feel like it is really asking for problems. I think the WAL position should advance and/or have a timeline change when undergoing upgrade so that the system can more reliably report bookkeeping error, and it'd be ideal if WAL was generated that applied those changes. For example: suppose pg_upgrade emitted full-page-write records in the format of the new postgres version on an unoccupied timeline. One can use PG.next tools to report on the first txid in the pg_upgrade generated WAL and then use standard point in time recovery features to halt replay on a PG.previous version, swap to the new timeline, and then start up PG.next on the new timeline, applying the full page writes to its catalogs before becoming consistent. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
