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: (view raw, whole thread or download thread mbox)
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).


Fujii Masao
NTT Open Source Software Center

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


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-2017 The PostgreSQL Global Development Group