Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

På torsdag 14. september 2017 kl. 21:13:56, skrev Bruce Momjian <
bruce(at)momjian(dot)us <mailto:bruce(at)momjian(dot)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