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

From Robert Haas
Subject Re: Re: synchronous_commit and synchronous_replication Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date
Msg-id BANLkTimi_EXTMSVOfGf0T92TFa=OB9XoBQ@mail.gmail.com
Whole thread Raw
In response to Re: Re: synchronous_commit and synchronous_replication Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Re: synchronous_commit and synchronous_replication Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.  (Greg Stark <gsstark@mit.edu>)
Re: Re: synchronous_commit and synchronous_replication Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
On Tue, Apr 5, 2011 at 3:53 AM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>>> The attached patch merges synchronous_replication into synchronous_commit.
>> Committed
>
> Without discussion?  I would think that this patch is stepping on the
> other one toes and that maybe would need to make a decision about sync
> rep behavior before to commit this change.

Err, I thought we did.  We had a protracted discussion of Simon's
patch: 9 people expressed an opinion; 6 were opposed.

With respect to this patch, the basic design was discussed previously
and Simon, Fujii Masao, Greg Stark and myself all were basically in
favor of something along these lines, and to the best of my
recollection no one spoke against it.

> Maybe it's just me, but I'm struggling to understand current community
> processes and decisions.

Well, I've already spent a fair amount of time trying to explain my
understanding of it, and for my trouble I got accused of being
long-winded.  Which is probably true, but makes me think I should
probably keep this response short.  I'm not unwilling to talk about
it, though, and perhaps someone else would like to chime in.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Marti Raudsepp
Date:
Subject: Re: Transforming IN (...) to ORs, volatility
Next
From: Robert Haas
Date:
Subject: Re: Proposal: q-gram GIN and GiST indexes