On Fri, Sep 15, 2017 at 01:23:45AM +0200, Andreas Joseph Krogh wrote:
> I tested upgrading from 9.6 to 10 now, using pg_upgrade, and pg_upgrade creates
> the new data-dir with pg_wal "in it" (just like regular initdb), so pg_upgrade
> seems not to care about where the old version's pg_xlog was. You have to move
> (by symlinking) pg_wal to a separate location manually *after* running
> pg_upgrade on the master. No special handling is needed when rsync'ing it over
> to the standby, so it doesn't need any --hard-links or --size-only, correct?
>
> Given the path, on the upgraded primary, to pg_wal is /custom/path/to/pg_wal,
> the rsync command will be:
>
> rsync --archive --delete /custom/path/to/pg_wal standby.example.com:/custom/
> path/to/pg_wal
>
> I think it's useful to mention this to eliminate any doubt.
>
> I also think it's worth mentioning that you have to manually move pg_wal to a
> custom location after running pg_upgrade as it will not preserve/use the old
> path.
Thinking some more, you are right that there is no need to rsync the
_old_ primary WAL directory since it is the same on the standby old WAL
directory, and there are no links between the old and new WAL
directories, so you could just do the new one, or just copy it and not
even use rsync.
However, I think it adds complexity to try to optimize the copy of the
WAL files and we are better just requiring them to use the same steps
for WAL copy that they _must_ use for the data directory and
tablespaces because of the links between old and new files there.
Agreed?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers