On 8/2/07, Andrew Hammond <andrew.george.hammond at gmail.com> wrote:
>
>
>
> > Lag of 1-10 seconds is really usual. It's an unavoidable evil for slony,
> > unfortunately.
>
>
> I agree that, given the existing design, a lag is unavoidable. Hence the
> term asynchronous. Exactly how is this evil? It's _exactly_ what the syst=
em
> is designed to be.
>

No, "the evil" is not always "the bad" nor "very-very bad, ghrrr". The evil
is "the evil", and nothing more. We have to live with it, no more, no less.
:-)

And I wanded to say that in a lot of cases (e.g. - for realtime websites!)
the "asynchronous replication" is quite acceptable, if we read a critical
data from the origin time to time (when a replica is not ready enough). No
need to refer to non-existed "synchronous replication" in that case - it's
useless, and that is what I meant.

Instead of saying about a "synchronous replication", it is better to explain
an algorythm of checking if a replica is ready enough comparing to the
origin state in the past. I have asked this question many time (in this list
and directly), but seems people do not understand why this checking is so
needed and say common words about "synchronous replication" and
"impossibility" of such check without any detalizations. So the answer was
practically empty in these cases. I will be very glad if anybody of Slony
gurus would agree to spend a hour of his time speaking single-minded (!)
about this subject, because it is very useful for anybody who uses Slony for
heavy-loaded websites. Without fast words "impossible" and "synchronous
replication", because for this task the solution have to exist (I am pretty
sure).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20070803/=
6bca7bde/attachment-0001.htm