Re: standby registration (was: is sync rep stalled?)

On Thu, Oct 7, 2010 at 7:15 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Josh Berkus wrote:
>>
>> This version of Standby Registration seems to add One More Damn Place
>> You Need To Configure Standby (OMDPYNTCS) without adding any
>> functionality you couldn't get *without* having a list on the master.
>> Can someone explain to me what functionality is added by this approach
>> vs. not having a list on the master at all?
>>
>
> That little design outline I threw out there wasn't intended to be a plan
> for right way to proceed here.  What I was trying to do is point out the
> minimum needed that would actually work for the use cases people want the
> most, to shift discussion back toward simpler rather than more complex
> configurations.  If a more dynamic standby registration procedure can get
> developed on schedule that's superior to that, great.  I think it really
> doesn't have to offer anything above automating what I outlined to be
> considered good enough initially though.
>
> And if the choice is between the stupid simple OMDPYNTCS idea I threw out
> and demanding a design too complicated to deliver in 9.1, I'm quite sure I'd
> rather have the hard to configure version that ships.  Things like keeping
> the master from having a hard-coded list of nodes and making it easy for
> every node to have an identical postgresql.conf are all great goals, but are
> also completely optional things for a first release from where I'm standing.
>  If a patch without any complicated registration stuff got committed
> tomorrow, and promises to add better registration on top of it in the next
> CommitFest didn't deliver, the project would still be able to announce "Sync
> Rep is here in 9.1" in a way people could and would use.  We wouldn't be
> proud of the UI, but that's normal in a "release early, release often"
> world.
>
> The parts that scare me about sync rep are not in how to configure it, it's
> in how it will break in completely unexpected ways related to the
> communications protocol.  And to even begin exploring that fully, something
> simple has to actually get committed, so that there's a solid target to kick
> off organized testing against.  That's the point I'm concerned about
> reaching as soon as feasible.  And if takes massive cuts in the flexibility
> or easy of configuration to get there quickly, so long as it doesn't
> actually hamper the core operating set here I would consider that a good
> trade.

Yes, let's please just implement something simple and get it
committed. k = 1. Two GUCs (synchronous_standbys = name, name, name
and synchronous_waitfor = none|recv|fsync|apply), SUSET so you can
change it per txn. Done. We can revise it *the day after it's
committed* if we agree on how. And if we *don't* agree, then we can
ship it and we still win.

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