On 10/06/2010 09:04 PM, Dimitri Fontaine wrote: > Ok so I think we're agreeing here: what I said amounts to propose that > the code does work this way when the quorum is such setup, and/or is > able to reject any non-read-only transaction (those that needs a real > XID) until your standby is fully in sync. > > I'm just saying that this should be an option, not the only choice.
I'm sorry, I just don't see the use case for a mode that drops guarantees when they are most needed. People who don't need those guarantees should definitely go for async replication instead. What does a synchronous replication mode that falls back to async upon failure give you, except for a severe degradation in performance during normal operation? Why not use async right away in such a case? > Depends, lots of things out there work quite well in best effort mode, > even if some projects needs more careful thinking. That's again the idea > of waiting forever or just continuing, there's a middle-ground which is > starting the system before reaching the durability requirements or > downgrading it to read only, or even off, until you get them. In such cases the admin should be free to reconfigure the quorum. And yes, a read-only mode might be feasible. Please just don't fool the admin with a "best effort" things that guarantees nothing (but trouble). > If you ask for a quorum larger than what the current standbys are able > to deliver, and you're set to wait forever until the quorum is reached, > you just blocked the master. Correct. That's the intended behavior. > Good news is that the quorum is a per-transaction setting I definitely like the per-transaction thing. > so opening a > superuser connection to act on the currently waiting transaction is > still possible (pass/fail, but fail is what at this point? shutdown to > wait some more offline?). Not sure I'm following here. The admin will be busy re-establishing (connections to) standbies, killing transactions on the master doesn't help anything - whether or not the master waits forever. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
