On Tue, Jul 17, 2012 at 04:49:39PM -0700, Daniel Farina wrote: > 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.
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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
