From: | Yeb Havinga <yebhavinga(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: is sync rep stalled? |
Date: | 2010-09-30 14:54:03 |
Message-ID: | 4CA4A48B.90104@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> On 30.09.2010 17:09, Kevin Grittner wrote:
>> Aidan Van Dyk<aidan(at)highrise(dot)ca> wrote:
>> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-09-30 15:00:58 | Re: Using streaming replication as log archiving |
Previous Message | Aidan Van Dyk | 2010-09-30 14:39:23 | Re: Using streaming replication as log archiving |