Re: BUG #14999: pg_rewind corrupts control file global/pg_control
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, TipTop Labs <office@tiptop-labs.com>, Michael Paquier <michael.paquier@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2018-03-07T01:46:24Z
Lists: pgsql-bugs, pgsql-hackers
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
Commits
-
Add note in pg_rewind documentation about read-only files
- 378f78da8628 9.5.14 landed
- 741ad15f3b83 9.6.10 landed
- 423039779165 10.5 landed
- 0e4a46670e3a 11.0 landed
- eb270b00b2d6 12.0 landed