Re: xlog.c: WALInsertLock vs. WALWriteLock

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: fazool mein <fazoolmein(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: xlog.c: WALInsertLock vs. WALWriteLock
Date: 2010-10-26 19:02:27
Message-ID: AANLkTinAroFJnL4sAER8Z3c24Na0Qwc38QNUGiMdGn=8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 26, 2010 at 3:00 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> I agree that the standby might get ahead, but this doesn't necessarily
>> lead to database corruption. Here, the interesting case is what happens
>> when the primary fails, which can lead to *either* of the following two
>> cases:
>> 1) The standby, due to some triggering mechanism, becomes the new
>> primary. In this case, even if the standby was ahead, its fine.
>> 2) The primary comes back as primary. In this case, the standby will
>> connect again to the primary. At this point, *if* somehow we are able to
>> detect that the standby is ahead, then we should abort the standby and
>> create a standby from scratch.
>
> Yes.  And we weren't able to implement that for 9.0.  It's worth
> revisiting for 9.1.  In fact, the issue of "is the standby ahead of the
> master" has come up repeatedly in potential failure scenarios; I think
> we're going to need a fairly bulletproof method to determine this.

Agreed.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2010-10-26 19:09:01 Re: foreign keys for array/period contains relationships
Previous Message Josh Berkus 2010-10-26 19:00:05 Re: xlog.c: WALInsertLock vs. WALWriteLock