Re: pg_rewind, a tool for resynchronizing an old master after failover - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: pg_rewind, a tool for resynchronizing an old master after failover
Date
Msg-id 519E5493.5060800@vmware.com
Whole thread Raw
In response to Re: pg_rewind, a tool for resynchronizing an old master after failover  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg_rewind, a tool for resynchronizing an old master after failover  (Pavan Deolasee <pavan.deolasee@gmail.com>)
List pgsql-hackers
On 23.05.2013 07:55, Robert Haas wrote:
> On Thu, May 23, 2013 at 7:10 AM, Heikki Linnakangas
> <hlinnakangas@vmware.com>  wrote:
>> 1. Scan the WAL log of the old cluster, starting from the point where
>> the new cluster's timeline history forked off from the old cluster. For each
>> WAL record, make a note of the data blocks that are touched. This yields a
>> list of all the data blocks that were changed in the old cluster, after the
>> new cluster forked off.
>
> Suppose that a transaction is open and has written tuples at the point
> where WAL forks.  After WAL forks, the transaction commits.  Then, it
> hints some of the tuples that it wrote.  There is no record in WAL
> that those blocks are changed, but failing to revert them leads to
> data corruption.

Bummer, you're right. Hmm, if you have checksums enabled, however, we'll 
WAL log a full-page every time a page is dirtied for setting a hint bit, 
which fixes the problem. So, there's a caveat with pg_rewind; you must 
have checksums enabled.

- Heikki



pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: gemulon.postgresql.org/gitmaster.postgresql.org
Next
From: Heikki Linnakangas
Date:
Subject: Re: pg_rewind, a tool for resynchronizing an old master after failover