On Thu, Jul 26, 2012 at 2:26 PM, Jeff Davis <pgsql@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
