| 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:13:15 |
| Message-ID: | CAAZKuFYH8dW=9=RM5fn21L2pCLQSDxf9-OsTO5eB=E9QxXbFqA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jul 26, 2012 at 3:01 PM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
> 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
and by txid I meant WAL position, which mucks it up a bit because
that's not an option on old Postgres-es. But the overall point is the
same: I think pg_upgrade would be much more safe and usable in the
standby setting if it emitted data that depend upon a posterior
WAL-position at the point the cluster diverges onto a new timeline
that is the new version of Postgres, and it would be nice if that data
incremented the WAL position rather than being applied out-of-band.
And, it seems that emitting full page image records in the format of
the new version is a way to accomplish that.
--
fdr
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2012-07-26 23:24:43 | Re: Using pg_upgrade on log-shipping standby servers |
| Previous Message | Daniel Farina | 2012-07-26 22:01:55 | Re: Using pg_upgrade on log-shipping standby servers |