From: Simon Riggs <simon@2ndQuadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Greg Stark <gsstark@mit.edu>
Cc: Fujii Masao <masao.fujii@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date: Fri, 18 Mar 2011 15:40:57 +0000
Message-ID: <1300462857.18619.14696.camel@ebony> (raw)
In-Reply-To: <AANLkTikmbNW=phsUiXJMLv7AaptObRL-pCea-Si-T=ms@mail.gmail.com>
References: <E1PwMns-00047O-UU@gemulon.postgresql.org>
<AANLkTikJmP+bo1N-mFUWEpJiV6_OKisYw512OGeTJUbm@mail.gmail.com>
<AANLkTinHrymKd56m5AfawCdujuNM6B2g_--9UiOSSKGx@mail.gmail.com>
<AANLkTinbJDsrkF9rsy8Wh_hrrrPP7CQaNcND_1A-aLMe@mail.gmail.com>
<AANLkTi=f+EtkPU+rRgz=Ay-X80OvCGvxK_O6LpL9_dss@mail.gmail.com>
<AANLkTi=koHqna9WMm8_ATJN6c1GOLLp_0Tx6VswKhAdi@mail.gmail.com>
<AANLkTimVQe4RNqG6jb4XgxSxe2u_3oh+8Jzssn5jDE65@mail.gmail.com>
<AANLkTikmbNW=phsUiXJMLv7AaptObRL-pCea-Si-T=ms@mail.gmail.com>
On Fri, 2011-03-18 at 11:07 -0400, Robert Haas wrote:
> On Fri, Mar 18, 2011 at 10:55 AM, Greg Stark <gsstark@mit.edu> wrote:
> > On Thu, Mar 17, 2011 at 5:46 PM, Robert Haas <robertmhaas@gmail.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 much prefer a single switch, which is what I originally suggested.
Changing the meaning of synchronous_commit seems a problem.
durability = localmemory
durability = localdisk
(durability = remotereceive - has no meaning in current code)
durability = remotedisk
durability = remoteapply
it also allows us to have in the future
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: simon@2ndQuadrant.com, robertmhaas@gmail.com, gsstark@mit.edu, masao.fujii@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
In-Reply-To: <1300462857.18619.14696.camel@ebony>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox