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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
