Re: Configuring synchronous replication - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Configuring synchronous replication
Date
Msg-id AANLkTinnVYOj4LCP9jFYjWpEPTs0Rhy3nv9D=DvQs2pZ@mail.gmail.com
Whole thread Raw
In response to Re: Configuring synchronous replication  (Dimitri Fontaine <dfontaine@hi-media.com>)
Responses Re: Configuring synchronous replication
List pgsql-hackers
On Sat, Sep 18, 2010 at 4:36 AM, Dimitri Fontaine
<dfontaine@hi-media.com> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> On Fri, 2010-09-17 at 21:20 +0900, Fujii Masao wrote:
>>> What synchronization level does each combination of sync_replication
>>> and sync_replication_service lead to?
>>
>> There are only 4 possible outcomes. There is no combination, so we don't
>> need a table like that above.
>>
>> The "service" specifies the highest request type available from that
>> specific standby. If someone requests a higher service than is currently
>> offered by this standby, they will either
>> a) get that service from another standby that does offer that level
>> b) automatically downgrade the sync rep mode to the highest available.
>
> I like the a) part, I can't say the same about the b) part. There's no
> reason to accept to COMMIT a transaction when the requested durability
> is known not to have been reached, unless the user said so.

Yep, I can imagine that some people want to ensure that *all* the
transactions are synchronously replicated to the synchronous standby,
without regard to sync_replication. So I'm not sure if automatic
downgrade/upgrade of the mode makes sense. We should introduce new
parameter specifying whether to allow automatic degrade/upgrade or not?
It seems complicated though.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: .gitignore files, take two
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: libpq changes for synchronous replication