Re: Inconsistent DB data in Streaming Replication

Amit Kapila <amit(dot)kapila(at)huawei(dot)com> writes:
> On Wednesday, April 10, 2013 3:42 PM Samrat Revagade wrote:
>> Sorry, this is incorrect. Streaming replication continuous, master is not
>> waiting, whenever the master writes the data page it checks that the WAL
>> record is written in standby till that LSN.

> I am not sure it will resolve the problem completely as your old-master can
> have some WAL extra then new-master for same timeline. I don't remember
> exactly will timeline switch feature
> take care of this extra WAL, Heikki can confirm this point?
> Also I think this can serialize flush of data pages in checkpoint/bgwriter
> which is currently not the case.

Yeah. TBH this entire discussion seems to be "let's cripple performance
in the normal case so that we can skip doing an rsync when resurrecting
a crashed, failed-over master". This is not merely optimizing for the
wrong thing, it's positively hazardous. After a fail-over, you should
be wondering whether it's safe to resurrect the old master at all, not
about how fast you can bring it back up without validating its data.
IOW, I wouldn't consider skipping the rsync even if I had a feature
like this.

regards, tom lane