On Wednesday, June 20, 2012 09:41:03 PM Aidan Van Dyk wrote: > On Wed, Jun 20, 2012 at 3:27 PM, Andres Freund <and...@2ndquadrant.com> wrote: > >> 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. > > So why isn't the LSN good enough for when C propagates the change back to > A? Because every node has individual progress in the wal so the lsn doesn't mean anything unless you know from which node it originally is.
> Why does A need more information than C? Didn't I explain that two mails up? Perhaps Chris' phrasing explains the basic idea better: On Wednesday, June 20, 2012 07:06:28 PM Christopher Browne wrote: > The case where it would be needful is if you are in the process of > assembling together updates coming in from multiple masters, and need > to know: > - This INSERT was replicated from node #1, so should be ignored > downstream - That INSERT was replicated from node #2, so should be ignored > downstream - This UPDATE came from the local node, so needs to be passed > to downstream users Now imagine a scenario where #1 and #2 are in Europe and #3 and #4 in north america. #1 wants changes from #3 and #4 when talking to #3 but not those from #2 and itself (because that would be cheaper to get locally). 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
