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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: BUG #14999: pg_rewind corrupts control file global/pg_control
Дата
Msg-id 20180307014624.GC1744@paquier.xyz
обсуждение исходный текст
Ответ на Re: BUG #14999: pg_rewind corrupts control file global/pg_control  (Dmitry Dolgov <9erthalion6@gmail.com>)
Ответы Re: BUG #14999: pg_rewind corrupts control file global/pg_control
Список 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

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Index-only scan returns incorrect results when using acomposite GIST index with a gist_trgm_ops column.
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: Re: BUG #14999: pg_rewind corrupts control file global/pg_control