On 24.10.2013 14:15, Pavan Deolasee wrote:
> On Thu, Oct 24, 2013 at 4:22 PM, Heikki Linnakangas<hlinnakangas@vmware.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
