On Fri, May 11, 2012 at 2:17 PM, Tom Lane <tgl@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