From: | William Yu <wyu(at)talisys(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Postgresql replication |
Date: | 2005-08-25 21:13:14 |
Message-ID: | delc9f$30d4$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
David Goodenough wrote:
> The most obvious one that does exactly this (generic multi-master
> replication) is Lotus Domino. It is not a relational DB, but not sufficiently
> far off to stop the analogy.
>
> Domino marks each document with a binary value which identifies the
> server (built from a hash of the server name and the time the DB was
> created) and a timestamp when it was last modified, and also each document
> (record) has an ID (like OIDs). More recent versions also do this at a field
> level to avoid conflicts and speed replication. When two servers replicate
This system sounds ok for documents and general data that can always be
revived via version control/history. But I can't see how this would work
for financial transactions where you're dealing with money and bank
accounts. Suppose I have $100 in my account. I decided to login to
multiple servers and wire transfer $100 to another account on every
server. And I hit submit exactly at the same time for every server so
check. Sure they can resolve the conflict afterwards in terms of saying
in terms of which transfer to kill off. But the fact is that my other
account has that N x $100 already and I've just fleeced the bank.
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Browne | 2005-08-25 21:17:52 | Re: Postgresql replication |
Previous Message | Hossein S. Attar | 2005-08-25 21:03:51 | postgres optimizer |