Markus Wanner <markus@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