On Mon, Jun 29, 2015 at 4:55 AM, Heikki Linnakangas wrote:
> After thinking about this some more, I think it'd be acceptable if we just
> fail, if there are any non-writeable files in the data directory. The
> typical scenario is that postgresql.conf, or an SSL cert file, is a symlink
> to outside the data directory. It seems reasonable to require that the DBA
> just removes the symlink before running pg_rewind, and restores it
> afterwards if appropriate. In many cases, you would *not* want to overwrite
> your config files, SSL cert files, etc., so the DBA will need to script
> backing up and restoring those anyway.
Outnumbered I surrender. We are on the way of a doc patch then as
pg_rewind already fails in this scenario when trying to open the
target. What about the attached?
> (It's a fair question whether pg_rewind should be copying those files in the
> first place. I've opted for "yes", so that it's easy to explain the
> behaviour of pg_rewind: the end result is the same as if you took a new base
> backup from the source server. Whatever files you want to backup up before
> you re-initialize from a base backup, you should also backup with
> pg_rewind.)
We could then ignore all the symlinks in PGDATA except the ones that
are related to tablespaces, that's where the use of missing_ok for
pg_tablespace_location makes sense. pg_readlink would be useful for
pg_xlog in any case either way.
> 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.
Regards,
--
Michael
