Re: pg_rewind failure by file deletion in source server

On 06/29/2015 09:44 AM, Michael Paquier wrote:
> On Mon, Jun 29, 2015 at 4:55 AM, Heikki Linnakangas wrote:
>> But we'll still need to handle the pg_xlog symlink case somehow. Perhaps it
>> would be enough to special-case pg_xlog for now.
>
> Well, sure, pg_rewind does not copy the soft links either way. Now it
> would be nice to have an option to be able to recreate the soft link
> of at least pg_xlog even if it can be scripted as well after a run.

Hmm. I'm starting to think that pg_rewind should ignore pg_xlog
entirely. In any non-trivial scenarios, just copying all the files from
pg_xlog isn't enough anyway, and you need to set up a recovery.conf
after running pg_rewind that contains a restore_command or
primary_conninfo, to fetch the WAL. So you can argue that by not copying
pg_xlog automatically, we're actually doing a favour to the DBA, by
forcing him to set up the recovery.conf file correctly. Because if you
just test simple scenarios where not much time has passed between the
failover and running pg_rewind, it might be enough to just copy all the
WAL currently in pg_xlog, but it would not be enough if more time had
passed and not all the required WAL is present in pg_xlog anymore. And
by not copying the WAL, we can avoid some copying, as restore_command or
streaming replication will only copy what's needed, while pg_rewind
would copy all WAL it can find the target's data directory.

pg_basebackup also doesn't include any WAL, unless you pass the --xlog
option. It would be nice to also add an optional --xlog option to
pg_rewind, but with pg_rewind it's possible that all the required WAL
isn't present in the pg_xlog directory anymore, so you wouldn't always
achieve the same effect of making the backup self-contained.

So, I propose the attached. It makes pg_rewind ignore the pg_xlog
directory in both the source and the target.

- Heikki