Re: is sync rep stalled?

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

In response to

Responses

Browse pgsql-hackers by date

  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