Re: pg_rewind failure by file deletion in source server

On 06/26/2015 10:10 PM, Andres Freund wrote:
> On 2015-06-26 15:07:59 -0400, Robert Haas wrote:
>> I realize that the recent fsync fiasco demonstrated that people keep
>> files not readable by PG in the data directory
>
> It wasn't unreadable files that were the primary problem, it was files
> with read only permissions, no?

Right.

>> "oops, I can't read this, that's probably OK" just does not seem good
>> enough.
>
> Agreed.

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.

(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.)

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.

- Heikki