From: Bruce Momjian <bruce@momjian.us>
To: Andreas Joseph Krogh <andreas@visena.com>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Stephen Frost <sfrost@snowman.net>
Subject: Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)
Date: Sat, 16 Sep 2017 11:24:14 -0400
Message-ID: <20170916152414.GC9874@momjian.us> (raw)
In-Reply-To: <VisenaEmail.db.e5ceedc56ec1471.15e82123988@tc7-visena>
References: <20170914191356.GC6595@momjian.us>
<VisenaEmail.db.e5ceedc56ec1471.15e82123988@tc7-visena>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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 <bruce@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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: bruce@momjian.us, andreas@visena.com, michael.paquier@gmail.com, robertmhaas@gmail.com, sfrost@snowman.net
Subject: Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)
In-Reply-To: <20170916152414.GC9874@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox