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