On Wednesday, June 20, 2012 09:41:03 PM Aidan Van Dyk wrote:
> On Wed, Jun 20, 2012 at 3:27 PM, Andres Freund <andres@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