On Sep 1, 2015, at 1:47 PM, Robert Haas <robertmh...@gmail.com> wrote:
> Admittedly, there are some problems with snapshots here: if you don't > do anything special about snapshots, then what you have here will be > "eventually consistent" behavior. But that might be suitable for some > environments, such as very loosely coupled system where not all nodes > are connected all the time. Given that we’re discussing multi-node architectures here, you should expect that not all nodes will be connected at any time. Nodes fail, but the cluster should not. > And, for those environments where you do > need consistent snapshots, we can imagine ways to get that behavior, > like having the GTM consider the transaction uncommitted until it's > been logically replicated to every node. Again, you need a way to deal with nodes going down. I can envision building a cluster with twelve nodes replicated to each of three geographically-distributed data centers. Each replication/sync model needs to be able to handle nodes going up and down, data centers or racks going up or down, and nodes being added and removed. But even with smaller clusters, there’s no way around the fact that no system can guarantee that all nodes will be available at all times. Best, David
smime.p7s
Description: S/MIME cryptographic signature
