>> 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.
Sim