Markus Wanner <mar...@bluegap.ch> writes: >> 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.
We're still talking about freezing the master and all the applications when the first standby still has to do a base backup and catch-up to where the master currently is, right? > 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? It's all about the standard case you're building, sync rep, and how to manage errors. In most cases I want flexibility. Alert says standby is down, you lost your durability requirements, so now I'm building a new standby. Does it mean my applications are all off and the master refusing to work? I sure hope I can choose about that, if possible per application. Next step, the old standby has been able to boot again, thanks to the sysadmins who repaired it, so it's online again, and my replacement machine is doing a base-backup. Are all the applications still unavailable? I sure hope I have a word in this decision. >> 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. The idea here would be to be able to manually ACK a transaction that's waiting forever, because you know it won't have an answer and you'd prefer the application to just continue. But I see that's not a valid use case for you. 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
