Re: Standalone synchronous master - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Standalone synchronous master
Date
Msg-id 52D02A9E.2050704@2ndQuadrant.com
Whole thread Raw
In response to Re: Standalone synchronous master  (Simon Riggs <simon@2ndQuadrant.com>)
List 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 by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)