Skip site navigation (1) Skip section navigation (2)

Re: Synchronization levels in SR

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Synchronization levels in SR
Date: 2010-05-27 12:48:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, May 27, 2010 at 8:02 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Thu, May 27, 2010 at 8:28 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Thu, May 27, 2010 at 3:13 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)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
The Enterprise Postgres Company

In response to


pgsql-hackers by date

Next:From: Andres FreundDate: 2010-05-27 13:06:53
Subject: Re: pg_trgm
Previous:From: Tatsuo IshiiDate: 2010-05-27 12:40:41
Subject: Re: pg_trgm

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group