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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
