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

På lørdag 16. september 2017 kl. 17:24:14, skrev Bruce Momjian <bruce(at)momjian(dot)us
<mailto:bruce(at)momjian(dot)us>>:
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?
 
I'm a little unsure what scenario we're trying to describe here. Copying the
pg_wal separately (for which there's no need optimizing for) is only needed if
you've moved it out of $PGDATA _after_ running pg_upgrade, IIUC. So, I think it
should be clearly pointed out that copying pg_wal is only needed in those
cases, and that it can be done with whatever network-copying procedure you're
familiar with, ie. scp/rsync. This step is not similar to the steps required
for copying tablespaces outside $PGDATA, so it's worth documenting explicitly.
Maybe also telling users to ensure the synlink (in $PGDATA) to pg_wal on
standby points to pg_wal.
 
--
Andreas Joseph Krogh