Skip site navigation (1) Skip section navigation (2)

synchronous_commit and synchronous_replication Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

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: synchronous_commit and synchronous_replication Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date: 2011-04-04 08:54:04
Message-ID: BANLkTinEqPZ2yhzgAstO4XrYOYf9psEZRA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Mar 25, 2011 at 8:53 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> 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.

The attached patch merges synchronous_replication into synchronous_commit.
With the patch, valid values of synchronous_commit are "on" (waits for local
flush and sync rep), "off" (waits for neither local flush nor sync
rep), and "local"
(waits for only local flush).

Regards,

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

Attachment: merge_gucs_v1.patch
Description: application/octet-stream (16.8 KB)

Responses

pgsql-hackers by date

Next:From: Gabriele BartoliniDate: 2011-04-04 09:11:37
Subject: Uppercase SGML entity declarations
Previous:From: Dave PageDate: 2011-04-04 08:33:50
Subject: Re: FDW state from plan time

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group