|From:||Hannu Krosing <hannu(at)skype(dot)net>|
|To:||Markus Schiltknecht <markus(at)bluegap(dot)ch>|
|Cc:||Fujii Masao <fujii(dot)masao(at)oss(dot)ntt(dot)co(dot)jp>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Views:||Raw Message | Whole Thread | Download mbox|
Ühel kenal päeval, K, 2006-08-23 kell 13:36, kirjutas Markus
> Hannu Krosing wrote:
> > But if you have very few writes, then there seems no reason to do sync
> > anyway.
> I think there is one: high-availability. A standby-server which can
> continue if your primary fails. Of course sync is only needed if you
> absolutely cannot effort loosing any committed transaction.
Yes. I guess that for that an enchanced WAL-shipping would be ok.
Probably one where you require both sync to local disk and copy to
remote (without waiting for sync) to have happened in order to
> >> Another important factor is the amount of conflicting transactions.
> > That too, but just the need to do *any* locking on all nodes will
> > significantly slow down sync replication
> If you implement sync replication with locking, yes. But there are
> better ways: the Postgres-R approach does not do network locking, but
> aborts conflicting transactions just before committing. That results in
> much less network traffic (one GCS-message per writing-transaction).
but it still needs to do at least one network roundtrip + any needed
testing on all nodes + WAL sync on all nodes before it can COMMIT, no?
And I'm afraid that GCS serialisation will need more than one roundtrip
or risk being out-of-date.
I'm not saying that Postgres-R (or any other sync replication) is not
doable or even useful. I just can't see right away, how it can scale
very well for any significant write load.
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
|Next Message||Joshua D. Drake||2006-08-23 14:09:05||Re: Some minor changes to pgbench|
|Previous Message||Bruce Momjian||2006-08-23 14:00:57||Re: [HACKERS] COPY view|