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

> On 6 March 2018 at 02:39, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> On Mon, Mar 5, 2018 at 6:01 PM, Michael Paquier <michael@paquier.xyz> wrote:
>> On Mon, Mar 05, 2018 at 05:47:06PM +0900, Masahiko Sawada wrote:
>>> Since files other than relation files such as vm, fsm, WAL are
>>> categorize as FILE_ACTION_COPY_CONFIG, I think the name would cause
>>> misreading. For example, we can use FILE_ACTION_COPY_DATA and
>>> FILE_ACTION_COPY_OTHER?
>>
>> I am not stopped on a given name.
>
> Hmm, when I used pg_rewind --debug with this patch the debug message
> made me confused because almost database files appears with
> COPY_CONFIG. Also looking at the source code comment, it says
> COPY_CONFIG is aimed to configuration files. But these file are not
> configuration files actually. COPY_DATA makes sense to me, but
> COPY_CONFIG doesn't.
>
> Anyway, other than that the patch looks good to me. I'd like to wait
> for the Dmitory's review comment before marking this as "Ready for
> Commiter".

Thank you for waiting. Yes, it also looks good for me, but I'm wondering about
one thing - does it make sense to think about other error codes here, not only
about `EACCESS`? E.g. if a file was removed during the process (so, it should
be `ENOENT`), or something more exotic happened, like there are too many
symbolic links were encountered in resolving a pathname (`ELOOP`)?