Re: Re: [COMMITTERS] pgsql: Ensure age() returns a stable value rather than the latest value

On Fri, May 11, 2012 at 2:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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