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? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
