From: | Daniel Farina <daniel(at)heroku(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using pg_upgrade on log-shipping standby servers |
Date: | 2012-07-26 22:01:55 |
Message-ID: | CAAZKuFaeRVB6UBykOrQb6DgSVChCevE3VtOaL6bULmgEbgyV-A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 26, 2012 at 2:26 PM, Jeff Davis <pgsql(at)j-davis(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Farina | 2012-07-26 22:13:15 | Re: Using pg_upgrade on log-shipping standby servers |
Previous Message | Jeff Davis | 2012-07-26 21:26:16 | Re: Using pg_upgrade on log-shipping standby servers |