On Wed, Jul 1, 2015 at 2:21 AM, Heikki Linnakangas <hlinn...@iki.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
