Heikki Linnakangas wrote:
> On 30.09.2010 17:09, Kevin Grittner wrote:
>> Aidan Van Dyk<aidan@highrise.ca> wrote:
>> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> wrote:
>>
>>>> I'm sure there's several things you can accomplish with
>>>> synchronous replication, perhaps you could describe what the
>>>> important use case for you is?
>>
>>> I'm looking for "data durability", not "server query-ability"
>>
>> Same here. If we used synchronous replication, the important thing
>> for us would be to hold up the master for the minimum time required
>> to ensure remote persistence -- not actual application to the remote
>> database. We could tolerate some WAL replay time on recovery better
>> than poor commit performance on the master.
>
> You do realize that to be able to guarantee zero data loss, the master
> will have to stop committing new transactions if the streaming stops
> for any reason, like a network glitch. Maybe that's a tradeoff you
> want, but I'm asking because that point isn't clear to many people.
If there's a network glitch, it'd probably affect networked client
connections as well, so it would mean no extra degration of service.
-- Yeb