On Fri, 2010-10-08 at 11:27 +0300, Heikki Linnakangas wrote:
> On 08.10.2010 11:25, Simon Riggs wrote:
> > On Fri, 2010-10-08 at 10:56 +0300, Heikki Linnakangas wrote:
> >>>
> >>> Or what kind of customers do you think really need a no-lag solution for
> >>> read-only queries? In the LAN case, the lag of async rep is negligible
> >>> and in the WAN case the latencies of sync rep are prohibitive.
> >>
> >> There is a very good use case for that particular set up, actually. If
> >> your hot standby is guaranteed to be up-to-date with any transaction
> >> that has been committed in the master, you can use the standby
> >> interchangeably with the master for read-only queries.
> >
> > This is an important point. It is desirable, but there is no such thing.
> > We must not take any project decisions based upon that false premise.
> >
> > Hot Standby is never guaranteed to be up-to-date with master. There is
> > no such thing as certainty that you have the same data as the master.
>
> Synchronous replication in the 'replay' mode is supposed to guarantee
> exactly that, no?
>From the perspective of the person making the change on the master: yes.
If they make the change, wait for commit, then check the value on a
standby, yes it will be there (or a later version).
>From the perspective of an observer, randomly selecting a standby for
load balancing purposes: No, they are not guaranteed to see the "latest"
answer, nor even can they find out whether what they are seeing is the
latest answer.
What sync rep does guarantee is that if the person making the change is
told it succeeded (commit) then that change is safe on at least k other
servers. Sync rep is about guarantees of safety, not observability.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services