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

For what it's worth it seems to me this patch makrmes it at least
conceptually easier to add new modes like Simon plans, not harder. It's
worth making sure we pick names that still make sense when the new
functionality goes in of course.

The other question is whether it's "fair" that one kind of patch goes in and
not the other. Personally I feel changes to GUCs are the kind of thing we
most often want to do in alpha. Patches that change functionality require a
higher barrier and need to be fixing user complaints or bugs. My perception
was that Simon's patch was ggreenberg latter.
On Apr 5, 2011 12:52 PM, "Robert Haas" <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Apr 5, 2011 at 3:53 AM, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)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