On Wednesday, June 20, 2012 09:24:29 PM Aidan Van Dyk wrote: > On Wed, Jun 20, 2012 at 3:15 PM, Andres Freund <and...@2ndquadrant.com> wrote: > > To recap why we think origin_id is a sensible design choice: > > > > There are many sensible replication topologies where it does make sense > > that you want to receive changes (on node C) from one node (say B) that > > originated from some other node (say A). > > Reasons include: > > * the order of applying changes should be as similar as possible on all > > nodes. That means when applying a change on C that originated on B and > > if changes replicated faster from A->B than from A->C you want to be at > > least as far with the replication from A as B was. Otherwise the > > conflict ratio will increase. If you can recreate the stream from the > > wal of every node and still detect where an individual change > > originated, thats easy. > > OK, so in this case, I still don't see how the "origin_id" is even enough. > > C applies the change originally from A (routed through B, because it's > faster). But when it get's the change directly from A, how does it > know to *not* apply it again? The lsn of the change.
Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
