På torsdag 14. september 2017 kl. 21:13:56, skrev Bruce Momjian < br...@momjian.us <mailto:br...@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
