On Wednesday, June 20, 2012 03:54:43 PM Robert Haas wrote: > On Wed, Jun 20, 2012 at 9:43 AM, Andres Freund <and...@2ndquadrant.com> wrote: > >> If you do that, then, yes, > >> everything that you need to disentangle various network topologies > >> must be present in WAL. But what I'm saying is: don't do it like > >> that. Generate the LCRs just ONCE, at the origin node, and then pass > >> them around the network, applying them at every node. Then, the > >> information that is needed in WAL is confined to one bit: the > >> knowledge of whether or not a particular transaction is local (and > >> thus LCRs should be generated) or non-local (and thus they shouldn't, > >> because the origin already generated them and thus we're just handing > >> them around to apply everywhere). > > > > Sure, you can do it that way, but I don't think its a good idea. If you > > do it my way you *guarantee* that when replaying changes from node B on > > node C you have replayed changes from A at least as far as B has. Thats > > a really nice property for MM. > > You *can* get same with your solution but it starts to get complicated > > rather fast. While my/our proposed solution is trivial to implement. > > That's an interesting point. I agree that's a useful property, and > might be a reason not to just use a single-bit flag, but I still think > you'd be better off handling that requirement via some other method, > like logging the node ID once per transaction or something. That lets > you have as much metadata as you end up needing, which is a lot more > flexible than a 16-bit field, as Kevin, Heikki, and Tom have also > said. If it comes down to that I can definitely live with that. I still think making the filtering trivial so it can be done without any logic on a low level is a very desirable property but if not, so be it.
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