Re: BUG #14999: pg_rewind corrupts control file global/pg_control - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #14999: pg_rewind corrupts control file global/pg_control
Date
Msg-id 20180307014624.GC1744@paquier.xyz
Whole thread Raw
In response to Re: BUG #14999: pg_rewind corrupts control file global/pg_control  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: BUG #14999: pg_rewind corrupts control file global/pg_control
List pgsql-bugs
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.
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Index-only scan returns incorrect results when using acomposite GIST index with a gist_trgm_ops column.
Next
From: Dmitry Dolgov
Date:
Subject: Re: BUG #14999: pg_rewind corrupts control file global/pg_control