Re: Patch for fail-back without fresh backup

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
Cc: Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Samrat Revagade <revagade(dot)samrat(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch for fail-back without fresh backup
Date: 2013-10-24 12:15:51
Message-ID: 52690F77.4080903@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 24.10.2013 14:15, Pavan Deolasee wrote:
> On Thu, Oct 24, 2013 at 4:22 PM, Heikki Linnakangas<hlinnakangas(at)vmware(dot)com
>> wrote:
>
>> To fix that, pg_rewind could always start the rewinding process from the
>> last checkpoint before the point that the histories diverge, instead of the
>> exact point of divergence.
>
> Is that something required even if someone plans to use pg_rewind for a
> cluster with checksums enabled ? I mean since only first update after
> checkpoint is WAL logged, pg_rewind will break if another update happens
> after standby forks.

Yes. It's broken as it is, even when checksums are enabled - good catch.
I'll go change it to read all the WAL in the target starting from the
last checkpoint before the point of divergence.

> Or would the recovery logic apply first WAL without
> looking at the page lsn ? (Sorry, may be I should read the code instead of
> asking you)

WAL recovery does apply all the full-page images without looking at the
page LSN, but that doesn't help in this case. pg_rewind copies over the
blocks from the source server (= promoted standby) that were changed in
the target server (= old master), after the standby's history diverged
from it. In other words, it reverts the blocks that were changed in the
old master, by copying them over from the promoted standby. After that,
WAL recovery is performed, using the WAL from the promoted standby, to
apply all the changes from the promoted standby that were not present in
the old master. But it never replays any WAL from the old master. It
reads it through, to construct the list of blocks that were modified,
but it doesn't apply them.

> If we do what you are suggesting, it seems like a single line patch to me.
> In XLogSaveBufferForHint(), we probably need to look at this additional GUC
> to decide whether or not to backup the block.

Yeah, it's trivial to add such a guc. Will just have to figure out what
we want the user interface to be like; should it be a separate guc, or
somehow cram it into wal_level?

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2013-10-24 12:40:58 Re: Patch for fail-back without fresh backup
Previous Message Pavan Deolasee 2013-10-24 12:03:22 Re: Patch for fail-back without fresh backup