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 g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services and Support www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
