Re: Issues with Quorum Commit

On Wed, Oct 13, 2010 at 10:18 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Tue, Oct 12, 2010 at 11:50 PM, Robert Haas <robertmhaas(at)gmail(dot)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.

There's some kind of logic that rewinds to the beginning of the WAL
segment and tries to replay from there.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company