On Tue, Oct 12, 2010 at 11:50 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> There's another problem here we should think about, too. Suppose you
> have a master and two standbys. The master dies. You promote one of
> the standbys, which turns out to be behind the other. You then
> repoint the other standby at the one you promoted. Congratulations,
> your database is now very possible corrupt, and you may very well get
> no warning of that fact. It seems to me that we would be well-advised
> to install some kind of bullet-proof safeguard against this kind of
> problem, so that you will KNOW that the standby needs to be re-synced.
> I mention this because I have a vague feeling that timelines are
> supposed to prevent you from getting different WAL histories confused
> with each other, but they don't actually cover all the cases that can
> happen.
>
Why don't the usual protections kick in here? The new record read from
the location the xlog reader is expecting to find it has to have a
valid CRC and a correct back pointer to the previous record. If the
new wal sender is behind the old one then the new record it's sent
won't match up at all.
--
greg