Re: Issues with Quorum Commit
От | Dimitri Fontaine |
---|---|
Тема | Re: Issues with Quorum Commit |
Дата | |
Msg-id | m2ocb6hz9a.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | Re: Issues with Quorum Commit (Aidan Van Dyk <aidan@highrise.ca>) |
Ответы |
Re: Issues with Quorum Commit
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: