On Fri, Sep 15, 2017 at 10:21 AM, Stephen Frost <sfrost@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. My reference to clean up the contents of
pg_xlog refers to the moment the new cluster has been started. 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.
> I tend to agree that it'd be good for the documentation to address this,
> but this is all really getting to be a bit much for a manpage to be able
> to handle, I think..
Definitely.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers