Robert Haas <robertmh...@gmail.com> writes:
> ... I don't really see any particular merit in removing our own
> XID from the picture entirely: that changes the behavior more
> significantly for no particular benefit.
The merit would be in keeping the function's definition simple.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
