On 18/09/10 22:59, Robert Haas wrote:
> On Sat, Sep 18, 2010 at 4:50 AM, Simon Riggs<simon@2ndquadrant.com> wrote:
>> Waiting might sound attractive. In practice, waiting will make all of
>> your connections lock up and it will look to users as if their master
>> has stopped working as well. (It has!). I can't imagine why anyone would
>> ever want an option to select that; its the opposite of high
>> availability. Just sounds like a serious footgun.
>
> Nevertheless, it seems that some people do want exactly that behavior,
> no matter how crazy it may seem to you.
Yeah, I agree with both of you. I have a hard time imaging a situation
where you would actually want that. It's not high availability, it's
high durability. When a transaction is acknowledged as committed, you
know it's never ever going to disappear even if a meteor strikes the
current master server within the next 10 milliseconds. In practice,
people want high availability instead.
That said, the timeout option also feels a bit wishy-washy to me. With a
timeout, acknowledgment of a commit means "your transaction is safely
committed in the master and slave. Or not, if there was some glitch with
the slave". That doesn't seem like a very useful guarantee; if you're
happy with that why not just use async replication?
However, the "wait forever" behavior becomes useful if you have a
monitoring application outside the DB that decides when enough is enough
and tells the DB that the slave can be considered dead. So "wait
forever" actually means "wait until I tell you that you can give up".
The monitoring application can STONITH to ensure that the slave stays
down, before letting the master proceed with the commit.
With that in mind, we have to make sure that a transaction that's
waiting for acknowledgment of the commit from a slave is woken up if the
configuration changes.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com