From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: TipTop Labs <office@tiptop-labs.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Subject: Re: BUG #14999: pg_rewind corrupts control file global/pg_control
Date: Sun, 8 Apr 2018 07:22:58 +0900
Message-ID: <20180407222258.GA3345@paquier.xyz> (raw)
In-Reply-To: <15971.1523116292@sss.pgh.pa.us>
References: <CA+q6zcWix34kmuB6PTgizy4-7Eq2Rn4FX3tpwnH5SdgEU7ugPw@mail.gmail.com>
<30255.1522711675@sss.pgh.pa.us>
<20180403024110.GB1621@paquier.xyz>
<A89569FD-1CCB-4060-932B-B61DD0F756BF@tiptop-labs.com>
<20180404072625.GB2208@paquier.xyz>
<22961.1522867812@sss.pgh.pa.us>
<20180405013818.GC1732@paquier.xyz>
<E1979209-A39E-4229-BBE0-59BC43FB4691@tiptop-labs.com>
<20180405065840.GH1732@paquier.xyz>
<15971.1523116292@sss.pgh.pa.us>
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.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: michael@paquier.xyz, tgl@sss.pgh.pa.us, office@tiptop-labs.com, 9erthalion6@gmail.com, sawada.mshk@gmail.com
Subject: Re: BUG #14999: pg_rewind corrupts control file global/pg_control
In-Reply-To: <20180407222258.GA3345@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox