On Mon, Jul 16, 2012 at 5:29 PM, Jeff Davis <pg...@j-davis.com> wrote: > On Tue, 2012-07-10 at 11:50 -0400, Bruce Momjian wrote: >> I don't think we can assume that because pg_upgrade was run on the >> master and standby that they are binary identical, can we? Technically >> the user file are identical, but the system catalogs and WAL might be >> different, hence my suggestion to run rsync before allowing the standby >> to rejoin the primary. > > Do you have plans to change that in the future? > > If we know that the user data files are identical between primary and > replica, it would be nice if we could provide a robust way to avoid > copying them.
How about this alternative that may sound crazy, but would lend itself to some unification in archiving: Could pg_upgrade emit WAL segment(s) to provide continuity of a timeline? So something like: * 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. * 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. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
