From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(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-09-08 13:32:54 |
Message-ID: | AANLkTikv1w-cGFZkfR8N9nHnhM1gQ-RozsM-nTdSrUL-@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 8, 2010 at 10:07 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Sep 8, 2010 at 8:30 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> And in any event, there is ALWAYS a window of
>>> time during which the client doesn't know the transaction has
>>> committed but other transactions can potentially see its effects.
>>
>> Yep. The problem here is that synchronous replication is likely to
>> make the window very big.
>
> So what? If the correctness of your application depends on the
> *amount of time* this window lasts, it's already broken. It seems
> like you're arguing that we should artificially increase lock
> contention to guard against possible race conditions in user
> applications. That doesn't make any sense to me, so one of us is
> confused.
Yep ;) On second thought, the problem here is that the effects of
the transaction marked as committed but still waiting for replication
can disappear after failover.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-09-08 13:50:59 | Re: Synchronization levels in SR |
Previous Message | Sushant Sinha | 2010-09-08 13:22:16 | Re: english parser in text search: support for multiple words in the same position |