From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: TipTop Labs <office@tiptop-labs.com>,
        Dmitry Dolgov <9erthalion6@gmail.com>,
        Masahiko Sawada <sawada.mshk@gmail.com>,
        Michael Paquier <michael.paquier@gmail.com>,
        PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Subject: Re: BUG #14999: pg_rewind corrupts control file global/pg_control
In-reply-to: <20180404072625.GB2208@paquier.xyz>
References: <20180305075431.GH2266@paquier.xyz>
 <CAD21AoDiHUUguQ7UUyK_Z4icHM3OiP8OEkpgDCsT3fg3B-P2LA@mail.gmail.com>
 <20180305090111.GI2266@paquier.xyz>
 <CAD21AoC3zSRrCdn6SBh4-whtXT0hCKCwjZM16uH1s1CU3DY+iQ@mail.gmail.com>
 <CA+q6zcVCfeYoAmPyW5R+uxZ0MD6=ZunsW=uP0AS=B=RxB8M7Tg@mail.gmail.com>
 <20180307014624.GC1744@paquier.xyz>
 <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>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Wed, 04 Apr 2018 16:26:25 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <22960.1522867812.1@sss.pgh.pa.us>
Date: Wed, 04 Apr 2018 14:50:12 -0400
Message-ID: <22961.1522867812@sss.pgh.pa.us>
Precedence: bulk

Michael Paquier <michael@paquier.xyz> writes:
> So after that I falled back to your patch and began testing it, which is
> where I noticed that we can *never* give the insurance to recover a data
> folder on which an error has happened in the middle of a pg_rewind.  The
> reason for that is quite simple: even if the truncation has been moved
> down to the moment where the first chunk of a file is received, you may
> have already done work on some relation files.  Particularly, some of
> them may have been truncated down to a given size without a new range of
> blocks fetched from the source.  So the data folder would be in an
> inconsistent state if trying to rewind it again.

Yes, we certainly cannot guarantee that failure partway through pg_rewind
leaves a consistent state of the target data directory.  It is likely
worth pointing that out in the documentation.  Whether we can or should
do anything about it is a different question.

When I first started looking at this thread, I wondered if maybe somebody
had had in mind to create an active defense against starting a postmaster
in an inconsistent target cluster, by dint of intentionally truncating
pg_control before the transfer starts and not making it valid again till
the very end.  It's now clear from looking at the code that that's not
what's going on :-(.  But I wonder how hard it would be to make it so,
and whether that'd be worth doing if it's not too hard.

Actually, probably a safer way to attack that would be to remove or
rename the topmost PG_VERSION file, and then put it back afterwards.
That'd be far easier to recover from manually, if need be, than
clobbering pg_control.

In any case, that seems separate from the question of what to do with
read-only files in the data directory.  Should we push forward with
committing Michael's previous patch, and leave that issue for later?

			regards, tom lane