On Tue, Jul 17, 2012 at 11:55 AM, Jeff Davis <pg...@j-davis.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
