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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
