Re: Issues with Quorum Commit

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Markus Wanner <markus(at)bluegap(dot)ch>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Issues with Quorum Commit
Date: 2010-10-14 02:18:44
Message-ID: AANLkTikECrMuZ1nXs+byQbch=Xj-fxD7yuhOW5Zbgata@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2010-10-14 02:37:37 Re: wip: functions median and percentile
Previous Message Robert Haas 2010-10-14 02:18:14 Re: Slow count(*) again...