Re: Synchronization levels in SR

On 27/05/10 09:51, Simon Riggs wrote:
> On Thu, 2010-05-27 at 02:18 +0300, Heikki Linnakangas wrote:
>> In practice, hard synchronous "don't return ever until the commit hits
>> the standby" behavior is rarely what admins actually want, because it's
>> disastrous from an availability point of view. More likely, admins want
>> "wait for ack from standby, unless it's not responding, in which case to
>> hell with redundancy and just act like a single server". It makes sense
>> if you just want to make sure that the standby doesn't return stale
>> results when it's working properly, and you're not worried about
>> durability but I'm not sure it's very sound otherwise.
>
> Which is also crazy. If you're using synch rep its because you care
> deeply about durability.

No, not necessarily. As I said above, you might just want a guarantee 
that *if* you query the standby, you get up-to-date results. But if the 
standby is down for any reason, you don't care about it. That's a very 
sensible mode of operation, for example if you're offloading reads to 
the standby with something like pgpool.

In fact I have the feeling that that's the most common use case for 
synchronous replication, not a deep concern of durability.

> I agree that don't-return-ever isn't something anyone will want.
>
> What we need is a "COMMIT with ERROR" message!

Hmm, perhaps we could emit a warning with the commit. I'm not sure what 
an application could do with it, though.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com