-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >>> Yeah. One nasty property that async multi master solutions share is >>> that they change the definition of what 'COMMIT' means -- the database >>> can't guarantee the transaction is valid because not all the >>> supporting facts are necessarily known. Even after libpq gives you >>> the green light that transaction could fail an arbitrary length of >>> time later, and you can't rely in the assumption it's valid until >>> you've done some synchronizing with the other 'masters'. Maybe you >>> don't need to rely on that assumption so a 'fix it later, or possibly >>> never' methodology works well. Those cases unfortunately fairly rare >>> in the real world. >> I don't quite follow you here. Are you talking about *synchronous* multi-master? >> Async multi-master works just fine, as long as you are not expecting the >> servers to give the exact same answer at the exact same time. But certainly >> transactions are "valid". > Lets say you have a foreign key constraint on delete restrict. On one > master you delete the key as there are no child entities. On the other > master you add a child entity, which should prevent deleting the parent > record. Both masters allowed the transaction to be committed, which > means that the users have both been given acknowledgement that their > actions are valid. If the rules are that the guy who put in the child > wins that means the committed delete never happened. If the parent wins > that means that the insert of the child was illegal. Well, that's one way to look at it, but you have to remember to treat the async replication as the invisible hand of another session, that may change what you have just committed, just like any other user may. If I add a child entry, then user X deletes said entry, and then user Y deletes the parent entry, that is for all intent and purposes the same as what happens in a replication scenario. The difference is that technically I add the child entry, user Y deletes said entry, and /then/ user R (replication) deletes both the parent and child (or inserts the parent back in). But in both cases, both the child creator and the parent deleter receive back a "ok commit". If you have a very large async response time, and your application has a very tight control over things, it may cause a problem, but in real life the syncing happens quite quickly, and the window for even catching both writes, not to mention sorting it out, is quite small. And I would expect an application running against a MM database would be able to handle such events anyway. - -- Greg Sabino Mullane greg@xxxxxxxxxxxx End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201105282339 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk3hwKIACgkQvJuQZxSWSsgu9gCgpBrlVa5xvmRNdIdcstlv60oJ tQsAn0sPvDHNZI+CVIT46SP4mEP7aGLM =4c4P -----END PGP SIGNATURE----- -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
