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
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 |