Markus Wanner <mar...@bluegap.ch> writes: > There's no point in time I > ever mind if a standby is a "candidate" or not. Either I want to > synchronously replicate to X standbies, or not.
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. And that by having a clear view of the system's state, it's possible to have a clear error response policy set out. > This is an admin decision. Whether or not your standbies are up and > running or not, existing or just about to be bought, that doesn't have > any impact on your durability requirements. 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. You can read my proposal as a way to allow our users to choose between those two incompatible behaviours. > Of course, it doesn't make sense to wait-forever on *every* standby that > ever gets added. Quorum commit is required, yes (and that's what this > thread is about, IIRC). But with quorum commit, adding a standby only > improves availability, but certainly doesn't block the master in any > way. (Quite the opposite: it can allow the master to continue, if it has > been blocked before because the quorum hasn't been reached). 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. Good news is that the quorum is a per-transaction setting, 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?). Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
