Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10(upgrading standby servers) - Mailing list pgsql-hackers

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

pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: [HACKERS] [POC] hash partitioning
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Warnings "unrecognized node type" for some DDLs withlog_statement = 'ddl'