On Thu, May 27, 2010 at 8:02 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Thu, May 27, 2010 at 8:28 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, May 27, 2010 at 3:13 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>> (1) most standard case: 1 master + 1 "sync" standby (near)
>>> When the master goes down, something like a clusterware detects that
>>> failure, and brings the standby online. Since we can ensure that the
>>> standby has all the committed transactions, failover doesn't cause
>>> any data loss.
>>
>> How do you propose to guarantee that? ISTM that you have to either
>> commit locally first, or send the commit to the remote first. Either
>> way, the two events won't occur exactly simultaneously.
>
> Letting the transaction wait until the standby has received / flushed /
> replayed the WAL before it returns a "success" indicator to a client
> would guarantee that. This ensures that all transactions which a client
> knows as committed exist in the memory or disk of the standby. So we
> would be able to see those transactions from new master after failover.
There could still be additional transactions that the original master
has committed locally but were not acked to the client. I guess you'd
just work around that by taking a new base backup from the new master.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company