| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | Markus Wanner <markus(at)bluegap(dot)ch>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Jeff Davis <pgsql(at)j-davis(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Issues with Quorum Commit |
| Date: | 2010-10-08 08:27:11 |
| Message-ID: | 4CAED5DF.4090000@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yeb Havinga | 2010-10-08 08:29:56 | Re: standby registration (was: is sync rep stalled?) |
| Previous Message | Simon Riggs | 2010-10-08 08:25:01 | Re: Issues with Quorum Commit |