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

<p>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.<p>Theother question is whether it's "fair" that one kind of patch goes in and not the other. Personally I feel
changesto GUCs are the kind of thing we most often want to do in alpha. Patches that change functionality require a
higherbarrier and need to be fixing user complaints or bugs. My perception was that Simon's patch was ggreenberg
latter.<divclass="gmail_quote">On Apr 5, 2011 12:52 PM, "Robert Haas" <<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>wrote:<br type="attribution" />> On Tue, Apr 5,
2011at 3:53 AM, Dimitri Fontaine <<a href="mailto:dimitri@2ndquadrant.fr">dimitri@2ndquadrant.fr</a>> wrote:<br
/>>> Robert Haas <<a href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>> writes:<br
/>>>>>The attached patch merges synchronous_replication into synchronous_commit.<br />>>>
Committed<br/> >><br />>> Without discussion?  I would think that this patch is stepping on the<br
/>>>other one toes and that maybe would need to make a decision about sync<br />>> rep behavior before to
committhis change.<br /> > <br />> Err, I thought we did. We had a protracted discussion of Simon's<br />>
patch:9 people expressed an opinion; 6 were opposed.<br />> <br />> With respect to this patch, the basic design
wasdiscussed previously<br /> > and Simon, Fujii Masao, Greg Stark and myself all were basically in<br />> favor
ofsomething along these lines, and to the best of my<br />> recollection no one spoke against it.<br />> <br
/>>>Maybe it's just me, but I'm struggling to understand current community<br /> >> processes and
decisions.<br/>> <br />> Well, I've already spent a fair amount of time trying to explain my<br />>
understandingof it, and for my trouble I got accused of being<br />> long-winded. Which is probably true, but makes
methink I should<br /> > probably keep this response short. I'm not unwilling to talk about<br />> it, though,
andperhaps someone else would like to chime in.<br />> <br />> -- <br />> Robert Haas<br />> EnterpriseDB:
<ahref="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br /> > The Enterprise PostgreSQL Company<br
/></div>