From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Daniel Farina <daniel(at)heroku(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using pg_upgrade on log-shipping standby servers |
Date: | 2012-07-18 04:16:20 |
Message-ID: | 20120718041620.GA29910@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 17, 2012 at 04:49:39PM -0700, Daniel Farina wrote:
> On Tue, Jul 17, 2012 at 11:55 AM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> > On Tue, 2012-07-17 at 01:02 -0700, Daniel Farina wrote:
> >> Could pg_upgrade emit WAL segment(s) to provide continuity of a
> >> timeline? So something like:
> >
> > By "segments" did you mean "records"?
>
> Yes. It would be nicer not to have to tie it to the WAL segment file size.
>
> >> * Take down the writable primary for pg_upgrade
> >> * Some WAL is emitted and possibly archived
> >> * The old version, when reaching the special pg_upgrade WAL, could
> >> exit or report its situation having paused replay (as clearly, it
> >> cannot proceed). Unsure.
> >
> > I don't really understand this step.
>
> "Some WAL is emitted and possibly archived" needs a subject in that fragment:
>
> "pg_upgrade somehow (directly, or indirectly) emits and/or archives
> WAL used to complete binary-upgrade". That means that it should
> appear in the WAL stream and be subject to archive_command, like any
> other WAL.
>
> The sticky part is what the standby should do when it encounters the
> special wal-upgrade records. It should probably pause replay to allow
> some other program to stop the old postgres version and start the new
> version with the same cluster.
WAL is not guaranteed to be the same between PG major versions, so doing
anything with WAL is pretty much a no-go.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-07-18 04:18:30 | Re: BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2) |
Previous Message | Greg Smith | 2012-07-18 04:00:08 | Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation) |