Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On Tue, Mar 27, 2018 at 02:02:10PM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Mar 27, 2018 at 11:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> This is ignoring the possibility of damaged data in between, ie
>>> A ... B ... CHKPT ... C ... a few zeroed pages ... D ... CHKPT ... E ... F
>
>> It's hard for me to believe that this case matters very much. If
>> you're trying to run pg_rewind on a system where the WAL segments
>> contain a few zeroed pages, you're probably going to be hosed anyway,
>> if not by this particular thing then by something else.
>
> Well, the point of checkpoints is that WAL data before the last one
> should no longer matter anymore, isn't it?

I have to agree with Tom here. If you force pg_rewind to replay more
WAL records from a checkpoint older than the checkpoint prior to where
WAL has forked at promotion then you have a risk of losing data.
Remember, this comes close to the recent thread where we discussed that
keeping in pg_wal WAL segments worth more than the last completed
checkpoints could lead to corruption if you try to replay from that,
which led to 4b0d28d.
--
Michael