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

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.

--
Greg Smith, 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us