On Tue, Jul 27, 2010 at 10:12 PM, Joshua Tolley <eggyk...@gmail.com> wrote: > I don't think it can support the case you're interested in, though I'm not > terribly expert on it. I'm definitely not arguing for the syntax Oracle uses, > or something similar; I much prefer the flexibility we're proposing, and agree > with Yeb Havinga in another email who suggests we spell out in documentation > some recipes for achieving various possible scenarios given whatever GUCs we > settle on.
Agreed. I'll add it to my TODO list. > My concern is that in a quorum system, if the quorum number is less than the > total number of replicas, there's no way to know *which* replicas composed the > quorum for any given transaction, so we can't know which servers to fail to if > the master dies. What about checking the current WAL receive location of each standby by using pg_last_xlog_receive_location()? The standby which has the newest location should be failed over to. > This isn't different from Oracle, where it looks like > essentially the "quorum" value is always 1. Your scenario shows that all > replicas are not created equal, and that sometimes we'll be interested in WAL > getting committed on a specific subset of the available servers. If I had two > nearby replicas called X and Y, and one at a remote site called Z, for > instance, I'd set quorum to 2, but really I'd want to say "wait for server X > and Y before committing, but don't worry about Z". > > I have no idea how to set up our GUCs to encode a situation like that :) Yeah, quorum commit alone cannot cover that situation. I think that current approach (i.e., quorum commit plus replication mode per standby) would cover that. In your example, you can choose "recv", "fsync" or "replay" as replication_mode in X and Y, and choose "async" in Z. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers