On Fri, Jan 13, 2012 at 10:12 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Jeff Janes <jeff.janes@gmail.com> wrote:\
>
>> I don't understand why this is controversial.
>
> I'm having a hard time seeing why this is considered a feature. It
> seems to me what is being proposed is a mode with no higher
> integrity guarantee than asynchronous replication, but latency
> equivalent to synchronous replication.
There are never 100% guarantees. You could always have two
independent failures (the WAL disk of the master and of the slave)
nearly simultaneously.
If you look at weaker guarantees, then with asynchronous replication
you are almost guaranteed to lose transactions on a fail-over of a
busy server, and with the proposed option you are almost guaranteed
not to, as long as disconnections are rare.
As far as latency, I think there are many cases when a small latency
is pretty much equivalent to zero latency. A human on the other end
of a commit is unlikely to notice a latency of 0.1 seconds.
> I can see where it's
> tempting to want to think it gives something more in terms of
> integrity guarantees, but when I think it through, I'm not really
> seeing any actual benefit.
I think the value of having a synchronously replicated commit is
greater than zero but less than infinite. I don't think it is
outrageous to think that that value could be approximately expressed
in seconds you are willing to wait for that replicated commit before
going ahead without it.
>
> If this fed into something such that people got jabber message,
> emails, or telephone calls any time it switched between synchronous
> and stand-alone mode, that would make it a built-in monitoring,
> fail-over, and alert system -- which *would* have some value. But
> in the past we've always recommended external tools for such
> features.
Since synchronous_standby_names cannot be changed without bouncing the
server, we do not provide the tools for an external tool to make this
change cleanly.
Cheers,
Jeff
