On Wed, Jun 20, 2012 at 3:49 PM, Andres Freund <and...@2ndquadrant.com> wrote: > 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?
Probably, but that didn't mean I understood it... I'm trying to keep up here ;-) So the origin_id isn't strictly for the origin node to know filter an LCR it's applied already, but it is also to correlate the LSN's because the LSN's of the re-generated LCR's are meant to contain the originating nodes's LSN, and every every node applying LCRs needs to be able to know where it is in every node's LSN progress. I had assumed any LCR's generated on a node woudl be relative to the LSN sequencing of that node. > 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). Right, but if the link between #1 and #2 ever "slows down", changes from #3 and #4 may very well already have #2's changes, and even require them. #1 has to apply them, or is it going to stop applying LCR's from #3 when it see's LCRs from #3 coming in that originate on #2 and have LSNs greater than what it's so far received from #2? -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
