On Tue, 2010-05-25 at 13:31 -0400, Robert Haas wrote: > On Tue, May 25, 2010 at 1:10 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > > 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. > > Perhaps the difficulty here is that those still look like per-server > settings to me. Just maybe with a different set of semantics.
(Those are the per-server settings.) -- 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
