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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: TipTop Labs <office(at)tiptop-labs(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14999: pg_rewind corrupts control file global/pg_control
Date: 2018-04-07 22:22:58
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs pgsql-hackers

On Sat, Apr 07, 2018 at 11:51:32AM -0400, Tom Lane wrote:
> In any case, after another look at the code, it seems to me that it'd be
> pretty easy to get pg_rewind to notice at the start whether a target file
> it plans to overwrite is read-only: process_source_file is already doing
> an lstat per file, so I think a permissions check there wouldn't add much
> overhead. So at that point we could either bail out without damage, or
> decide to skip the file.

Yes, that's one of the methods I mentioned in my previous email. Now,
do we want to fail the run immediately if such a file is found? Or do
we want to report at once all such files so as the user does not need to
run multiple times pg_rewind. The latter would be much more useful.

A downside here is that the file from the source would still be fetched
and copied on the target. So a file which was in read-only would become
basically writable. Don't think that it is a big deal as the has
superuser rights at this point, but that's worth mentioning.

> We could still lose if permissions change midway
> through the run, but that's the sort of situation I think is OK to fail
> in.

If the file system switches to read-only in the middle of the run, I see
no way to recover from that. That would be bad luck, but it is way
better to fail hard and let the user that something has gone wrong. I
still think that we want to document that if pg_rewind fails hard
midflight, then the only thing safe enough moving forward is to use a
new base backup.

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2018-04-09 04:26:54 Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?
Previous Message Tom Lane 2018-04-07 15:51:32 Re: BUG #14999: pg_rewind corrupts control file global/pg_control

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-04-07 22:24:45 Searching for: Fast windows buildfarm animal
Previous Message Tom Lane 2018-04-07 22:09:38 Re: PATCH: Configurable file mode mask