Re: pg_rewind failure by file deletion in source server

On Wed, Jul 1, 2015 at 2:21 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> 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.

Those are very convincing arguments.

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

Minor thing: s/continous/continuous. Except that this patch looks sane to me.

(btw, it seems to me that we still have a race condition with
pg_tablespace_location).
--
Michael