Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
В списке pgsql-hackers по дате отправления:
| От | Markus Wanner |
|---|---|
| Тема | Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. |
| Дата | |
| Msg-id | 4D83B0EC.1010105@bluegap.ch обсуждение исходный текст |
| Ответ на | Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
| Список | pgsql-hackers |
On 03/18/2011 05:27 PM, Kevin Grittner wrote: > Basically, what Heikki addresses. It has to be committed after > crash and recovery, and deal with replicas which may or may not have > been notified and may or may not have applied the transaction. Huh? I'm not quite following here. Committing additional transactions isn't a problem, reverting committed transactions is. And yes, given that we only wait for ACK from a single standby, you'd have to failover to exactly *that* standby to guarantee consistency. > In fact, on further reflection, allowing other transactions to see > work before the committing transaction returns could lead to broken > behavior if that viewing transaction took some action based on the > that, the master crashed, recovery was done using a standby, and > that standby hadn't persisted the transaction. So this behavior is > necessary for good behavior. I fully agree to that. Regards Markus
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера