Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Fri, Sep 15, 2017 at 10:21 AM, Stephen Frost <sfr...@snowman.net> wrote: > > No, one of the baseline requirements of pg_upgrade is to *not* screw > > with the existing cluster. Removing its WAL or "cleaning it up" > > definitely seems like it's violating that principle. > > Not necessarily. Using --link it is game over for rollback once the > new cluster has started.
Yes, but not *before* the new cluster has started. > My reference to clean up the contents of > pg_xlog refers to the moment the new cluster has been started. Alright, that's technically beyond the scope of pg_upgrade then... > This > could be achieved with a pre-upgrade flag present on-disk that the > startup process looks at to perform actions needed. This flag of > course needs to depend on the version of the binary used to start > Postgres, and is written by pg_upgrade itself which links the new > cluster's pg_wal into the location of the old cluster. In short, if an > upgrade to PG version N is done, and that the flag related to the > cleanup of N is found, then actions happen. If Postgres is started > with a binary version N-1, nothing happens, and existing flags are > cleaned up. What I am not sure is if such extra machinery is worth > doing as things can be saved by just moving the soft link position of > the cluster after running pg_upgrade and before starting the new > cluster. Ugh. That strikes me as far more complication than would be good for this.. Thanks! Stephen
signature.asc
Description: Digital signature
