> That said, the timeout option also feels a bit wishy-washy to me. With a > timeout, acknowledgment of a commit means "your transaction is safely > committed in the master and slave. Or not, if there was some glitch with > the slave". That doesn't seem like a very useful guarantee; if you're > happy with that why not just use async replication?
Ah, I wasn't clear. My thought was that a standby which exceeds the timeout would be marked as "nonresponsive" and no longer included in the list of standbys which needed to be synchronized. That is, the timeout would be a timeout which says "this standby is down". > So the only case where standby registration is required is where you > deliberately choose to *not* have N+1 redundancy and then yet still > require all N standbys to acknowledge. That is a suicidal config and > nobody would sanely choose that. It's not a large or useful use case for > standby reg. (But it does raise the question again of whether we need > quorum commit). Thinking of this as a sysadmin, what I want is to have *one place* I can go an troubleshoot my standby setup. If I have 12 synch standbys and they're creating too much load on the master, and I want to change half of them to async, I don't want to have to ssh into 6 different machines to do so. If one standby needs to be taken out of the network because it's too slow, I want to be able to log in to the master and instantly identify which standby is lagging and remove it there. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers