From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. |
Date: | 2011-03-25 11:53:15 |
Message-ID: | AANLkTi=29RMsJpnkTgG8p=LzaS25d0KrRcGWSThctLUk@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Sat, Mar 19, 2011 at 12:07 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Mar 18, 2011 at 10:55 AM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
>> On Thu, Mar 17, 2011 at 5:46 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> What makes more sense to me after having thought about this more
>>> carefully is to simply make a blanket rule that when
>>> synchronous_replication=on, synchronous_commit has no effect. That is
>>> easy to understand and document.
>>
>> For what it's worth "has no effect" doesn't make much sense to me.
>> It's a boolean, either commits are going to block or they're not.
>>
>> What happened to the idea of a three-way switch?
>>
>> synchronous_commit = off
>> synchronous_commit = disk
>> synchronous_commit = replica
>>
>> With "on" being a synonym for "disk" for backwards compatibility.
>>
>> Then we could add more options later for more complex conditions like
>> waiting for one server in each data centre or waiting for one of a
>> certain set of servers ignoring the less reliable mirrors, etc.
>
> This is similar to what I suggested upthread, except that I suggested
> on/local/off, with the default being on. That way if you set
> synchronous_standby_names, you get synchronous replication without
> changing another setting, but you can say local instead if for some
> reason you want the middle behavior. If we're going to do it all with
> one GUC, I think that way makes more sense. If you're running sync
> rep, you might still have some transactions that you don't care about,
> but that's what async commit is for. It's a funny kind of transaction
> that we're OK with losing if we have a failover but we're not OK with
> losing if we have a local crash from which we recover without failing
> over.
I'm OK with this.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2011-03-25 12:12:05 | Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. |
Previous Message | User Masao_fujii | 2011-03-25 06:02:52 | pgbulkload - pgbulkload: Add new restriction: the password must be |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-03-25 11:54:55 | Re: Avoiding timeline generation |
Previous Message | Stephen Frost | 2011-03-25 11:49:33 | Re: Pre-set Hint bits/VACUUM FREEZE on data load..? |