På torsdag 14. september 2017 kl. 21:13:56, skrev Bruce Momjian <
bruce@momjian.us>:
On Thu, Sep 14, 2017 at 08:49:24PM +0200, Andreas Joseph Krogh wrote:
> I think the tablespace example is clear enough to modify for WAL and we
> instruct them right below that example to do WAL.
>
>
> Well, it's not following the exact same structure as there's no
> "version-directory" in pg_xlog, so the "rsync the version-dirs into it's parent
> on the target" isn't what's happening.
>
> That's why I think this makes sense to mention for the sake of a complete
> example:
>
> rsync --archive --delete --hard-links --size-only /vol1/postgres/9.6/pg_xlog \
> /vol1/postgres/10/pg_wal standby.example.com:/vol1/postgres/10/pg_wal
Well, there is technically no need for version directories in pgdata
either --- installers just create them.
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.
Thanks.
--
Andreas Joseph Krogh