On Fri, May 11, 2012 at 2:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > The merit would be in keeping the function's definition simple.
True. It's not *much* simpler, but it is simpler. > Anyway, let's see if breaking this down by cases clarifies anything. > As I see it, there are three possible cases: > > 1. On master, xact already has an XID. The longstanding behavior is > to use that XID as reference. The committed patch changes this to > reference whatever is next-to-assign XID at first call of age(), but > it's far from clear to me that that's better for this case in isolation. > > 2. On master, xact does not (yet) have an XID. The previous behavior > is to force XID assignment at first call of age(). However, if we > capture ReadNewTransactionId as per patch then we give the same answer > as we would have done before, only without assigning the xact an XID. > It could be argued that this can yield inconsistent results if the xact > later does something that forces XID assignment anyway, but surely > that's a pretty narrow corner case. > > 3. On slave, so xact cannot have an XID. Previous behavior is to fail > which we all agree is unhelpful. Capturing ReadNewTransactionId > provides behavior somewhat similar to patched case #2, though it's > unclear to me exactly how compatible it is given the likely skew between > master and slave notions of the next XID. > > It's arguable that what we should do is "use XID if on master, capture > ReadNewTransactionId if on slave", which would avoid any backwards > incompatibility for the first two cases while still fixing the case that > everybody agrees is a problem. Simon argues that this gives a weird > variance in the master vs slave behavior, but I'm not sure I believe > that's an issue. In case 2, the only way that the user can tell the > difference between force-XID-assignment and capture-ReadNewTransactionId > is if the transaction later does something requiring an XID, which > cannot happen anyway on the slave. So from here the difference in these > behaviors seems minimal and not worth creating incompatibility in the > first two cases for. Yeah. I don't think I particularly care what we do in HEAD, but it sure seems like it would be nice to change the back-branch behavior as little as possible. -- 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
