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

From Dmitry Dolgov
Subject Re: BUG #14999: pg_rewind corrupts control file global/pg_control
Date
Msg-id CA+q6zcVCfeYoAmPyW5R+uxZ0MD6=ZunsW=uP0AS=B=RxB8M7Tg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #14999: pg_rewind corrupts control file global/pg_control  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: BUG #14999: pg_rewind corrupts control file global/pg_control
List pgsql-bugs
> 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`)?


pgsql-bugs by date:

Previous
From: David Steele
Date:
Subject: Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Index-only scan returns incorrect results when using acomposite GIST index with a gist_trgm_ops column.