Aidan Van Dyk <ai...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
