Hi,
Hannu Krosing wrote:
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?
No. It only needs the 'roundtrip' in the sense that a transaction sends
out its writeset and has to wait for the GCS to have it serialized (i.e.
the GCS sends the message back to the sender node).
Then all nodes do the testing and WAL sync independently. (As Neil
recently pointed out in [1] this opens a small risk for data loss in the
case all nodes crash.)
And I'm afraid that GCS serialisation will need more than one roundtrip
or risk being out-of-date.
The spread people did some tests on 20 pentium machines connected via
100mbit ethernet. In [2] they state that it takes between 1.7 to 2.8 ms
(depending on the message size) to 'serialize' a message within this
group of 20 nodes.
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.
Sure, sync replication won't solve everybody's problems. But out of all
the sync replication algorithms, Postgres-R is my clear favorite. ;-)
Regards
Markus
[1]:
http://pgfoundry.org/pipermail/postgres-r-general/2006-August/000001.html
[2]: The Spread Toolkit: Architecture and Performance by Yair Amir,
Claudiu Danilov, Michal Miskin-Amir, John Schultz, Jonathan Stanton
http://www.cnds.jhu.edu/pub/papers/cnds-2004-1.pdf
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
