Re: BUG #14999: pg_rewind corrupts control file global/pg_control

On Sat, Apr 07, 2018 at 11:51:32AM -0400, Tom Lane wrote:
> In any case, after another look at the code, it seems to me that it'd be
> pretty easy to get pg_rewind to notice at the start whether a target file
> it plans to overwrite is read-only: process_source_file is already doing
> an lstat per file, so I think a permissions check there wouldn't add much
> overhead.  So at that point we could either bail out without damage, or
> decide to skip the file.

Yes, that's one of the methods I mentioned in my previous email.  Now,
do we want to fail the run immediately if such a file is found?  Or do
we want to report at once all such files so as the user does not need to
run multiple times pg_rewind.  The latter would be much more useful.

A downside here is that the file from the source would still be fetched
and copied on the target.  So a file which was in read-only would become
basically writable.  Don't think that it is a big deal as the has
superuser rights at this point, but that's worth mentioning.

> We could still lose if permissions change midway
> through the run, but that's the sort of situation I think is OK to fail
> in.

If the file system switches to read-only in the middle of the run, I see
no way to recover from that.  That would be bad luck, but it is way
better to fail hard and let the user that something has gone wrong.  I
still think that we want to document that if pg_rewind fails hard
midflight, then the only thing safe enough moving forward is to use a
new base backup.
--
Michael