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