> On 7 March 2018 at 02:46, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Tue, Mar 06, 2018 at 09:37:34PM +0100, Dmitry Dolgov wrote:
>> 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`)?
>
> The presence of the file is ensured in the pre-phase which builds the
> file map (see process_source_file), and actions are taken depending on
> the presence of a file on the source and the target. So a file missing
> on the target after those pre-checks have ensured that it was actually
> existing should be reported with ENOENT. ELOOP would as well be faced
> on the backend before seeing it in pg_rewind, no? In short, it seems to
> me that it is better to keep the code simple.
Ok, I agree. Then yes, this patch can be probably marked as ready.