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