Josh Berkus wrote:
However, I think we're getting way the heck away from how far we really want to go for 9.1. Can I point out to people that synch rep is going to involve a fair bit of testing and debugging, and that maybe we don't want to try to implement The World's Most Configurable Standby Spec as a first step?
I came up with the following initial spec for Most Configurable Standby Setup Ever recently:
-The state of all available standby systems is exposed via a table-like interface, probably an SRF. -As each standby reports back a result, its entry in the table is updated with what level of commit it has accomplished (recv, fsync, etc.) -The table-like list of standby states is then passed to a function, that you could write in SQL or whatever else makes you happy. The function returns a boolean for whether sufficient commit guarantees have been met yet. You can make the conditions required as complicated as you like. -Once that function returns true, commit on the master. Otherwise return to waiting for standby responses.
So that's what I actually want here, because all subsets of it proposed so are way too boring. If you cannot express every possible standby situation that anyone will ever think of via an arbitrary function hook, obviously it's not worth building at all.
Now, the more relevant question, what I actually need in order for a Sync Rep feature in 9.1 to be useful to the people who want it most I talk to. That would be a simple to configure setup where I list a subset of "important" nodes, and the appropriate acknowledgement level I want to hear from one of them. And when one of those nodes gives that acknowledgement, commit on the master happens too. That's it. For use cases like the commonly discussed "two local/two remote" situation, the two remote ones would be listed as the important ones.
Until something that simple is committed, tested, debugged, and had some run-ins with the real world, I have minimal faith that an attempt to anything more complicated has sufficient information to succeed. And complete faith that even trying will fail to deliver something for 9.1. The scope creep that seems to be happening here in the name of "this will be hard to change so it must be right in the first version" boggles my mind.
-- 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
