On Thu, Oct 7, 2010 at 7:15 PM, Greg Smith <g...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
