On Tue, 2010-05-25 at 11:52 -0500, Kevin Grittner wrote: > Robert Haas <robertmh...@gmail.com> wrote: > > Simon Riggs <si...@2ndquadrant.com> wrote: > >> If we define robustness at the standby level then robustness > >> depends upon unseen administrators, as well as the current > >> up/down state of standbys. This is action-at-a-distance in its > >> worst form. > > > > Maybe, but I can't help thinking people are going to want some > > form of this. The case where someone wants to do sync rep to the > > machine in the next rack over and async rep to a server at a > > remote site seems too important to ignore. > > I think there may be a terminology issue here -- I took "configure > by standby" to mean that *at the master* you would specify rules for > each standby. I think Simon took it to mean that each standby would > define the rules for replication to it. Maybe this issue can > resolve gracefully with a bit of clarification?
The use case of "machine in the next rack over and async rep to a server at a remote site" would require the settings server.nextrack = synch server.remotesite = async which leaves open the question of what happens when "nextrack" is down. In many cases, to give adequate performance in that situation people add an additional server, so the config becomes server.nextrack1 = synch server.nextrack2 = synch server.remotesite = async We then want to specify for performance reasons that we can get a reply from either nextrack1 or nextrack2, so it all still works safely and quickly if one of them is down. How can we express that rule concisely? With some difficulty. My suggestion is simply to have a single parameter (name unimportant) number_of_synch_servers_we_wait_for = N which is much easier to understand because it is phrased in terms of the guarantee given to the transaction, not in terms of what the admin thinks is the situation. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
