Aidan Van Dyk <aidan@highrise.ca> writes:
> Sure, but that lagged standy is already asynchrounous, not
> synchrounous. If it was synchronous, it would have slowed the master
> down enough it would not be lagged.
Agreed, except in the case of a joining standby. But you're saying it
better than I do:
> Yes, I believe you need to have a way for an admin (or
> process/control/config) to be able to "demote" a synchronous
> replication scenario into async (or "standalone", which is just an
> extension of really async). But it's no longer syncronous replication
> at that point. And if the choice is made to "keep trucking" while a
> new standby is being brought online and available and caught up,
> that's fine too. But during that perioud, until the slave is caught
> up and synchrounously replicating, it's *not* synchronous replication.
That's exactly my point. I think we need to handle the case and make it
obvious that this window is a data-loss window where there's no sync rep
ongoing, then offer users a choice of behaviour.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
