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>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using pg_upgrade on log-shipping standby servers |
Date: | 2012-07-17 23:49:39 |
Message-ID: | CAAZKuFYzAYY6EjGMb4ar30Bav899uEAjT9L+OFWVCJcEFGyO_g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
>> * Start up a new version of postgres on the same cluster at that
>> point, which plays the upgrade-WAL.
>>
>> I see this being pretty mechanically intensive, but right now my hands
>> are completely tied as to achieving total continuity of my archives,
>> costing a base-backup's worth of risk window upon upgrade.
>
> Does "continuity of archives" mean "avoid downtime" or "maintain a
> single WAL sequence".
The latter.
--
fdr
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2012-07-18 00:13:19 | Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation) |
Previous Message | Peter Geoghegan | 2012-07-17 23:48:50 | Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation) |