Date: Sat, 16 Sep 2017 12:34:51 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Andreas Joseph Krogh <andreas@visena.com>
Cc: Michael Paquier <michael.paquier@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
	Stephen Frost <sfrost@snowman.net>
Subject: Re: Clarification in pg10's pgupgrade.html
 step 10 (upgrading standby servers)
Message-ID: <20170916163451.GE9874@momjian.us>
References: <20170916152414.GC9874@momjian.us>
 <VisenaEmail.167.3c69dc1e033531bd.15e8b6a944d@tc7-visena>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <VisenaEmail.167.3c69dc1e033531bd.15e8b6a944d@tc7-visena>
User-Agent: Mutt/1.5.23 (2014-03-12)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On Sat, Sep 16, 2017 at 06:11:17PM +0200, Andreas Joseph Krogh wrote:
> 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

No.  If you ran initdb with --waldir on the new primary, you will create
a symbolic link in the PGDATA directory, and a directory outside of
PGDATA for storing the WAL.  When you run rsync on the new primary
PGDATA directory, you will copy the symlink in the PGDATA directory, but
it will point to probably nothing on the standby.

> 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.

Why tell them new instructions when the rsync instructions work fine? 
What is the value?

-- 
  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