Re: Sync Rep v19

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Sync Rep v19
Date: 2011-03-05 11:08:42
Message-ID: AANLkTikZwWkRxf2tYMc213Gk8U1xvtivvwN2xVmOw-mx@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Mar 5, 2011 at 7:28 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> Yes, that can happen. As people will no doubt observe, this seems to be
> an argument for wait-forever. What we actually need is a wait that lasts
> longer than it takes for us to decide to failover, if the standby is
> actually up and this is some kind of split brain situation. That way the
> clients are still waiting when failover occurs. WAL is missing, but
> since we didn't acknowledge the client we are OK to treat that situation
> as if it were an abort.

Oracle Data Guard in the maximum availability mode behaves that way?

I'm sure that you are implementing something like the maximum availability
mode rather than the maximum protection one. So I'd like to know how
the data loss situation I described can be avoided in the maximum availability
mode.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2011-03-05 12:16:49 Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)
Previous Message Simon Riggs 2011-03-05 11:04:45 Re: Sync Rep v19