Re: Standalone synchronous master
От | Hannu Krosing |
---|---|
Тема | Re: Standalone synchronous master |
Дата | |
Msg-id | 52D02A9E.2050704@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: Standalone synchronous master (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
On 01/10/2014 05:09 PM, Simon Riggs wrote: > On 10 January 2014 15:47, Bruce Momjian <bruce@momjian.us> wrote: > >> I know there was a desire to remove this TODO item, but I think we have >> brought up enough new issues that we can keep it to see if we can come >> up with a solution. > Can you summarise what you think the new issues are? All I see is some > further rehashing of old discussions. > > There is already a solution to the "problem" because the docs are > already very clear that you need multiple standbys to achieve commit > guarantees AND high availability. RTFM is usually used as some form of > put down, but that is what needs to happen here. If we want to get the guarantees that often come up in "sync rep" discussions - namely that you can assume that your change is applied on standby when commit returns - then we could implement this by returning LSN from commit at protocol level and having an option in queries on standby to wait for this LSN (again passed on wire below the level of query) to be applied. This can be mostly hidden in drivers and would need very little effort from end user to use. basically you tell the driver that one connection is bound as "the slave" of another and driver can manage using the right LSNs. That is the last LSN received from master is always attached to queries on slaves. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ
В списке pgsql-hackers по дате отправления: