Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node
От | Aidan Van Dyk |
---|---|
Тема | Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node |
Дата | |
Msg-id | CAC_2qU_ps53Ziv2y09aJ5ZL4XzDfjbdEg3_j117KmryzrsBqtA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node
|
Список | pgsql-hackers |
On Wed, Jun 20, 2012 at 3:49 PM, Andres Freund <andres@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 <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? 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, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
В списке pgsql-hackers по дате отправления: