On 11 May 2012 19:17, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>
> 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.
Case (2) is more complex than described. If we use XID always, then
the so-say stable value could change mid way through a scan when the
XID is assigned and would provide neither a stable, sensible nor a
backwards compatible response.
We can only use XID if it already exists AND age() has not yet been
executed by this transaction. Which is case (1).
Case (1) does show changed behaviour. I didn't regard that as
important because the normal use case for this is a short read only
request, so case (1) is not a typical usage of the function. Given
solving case (1) means breaking case (3), I'm not convinced it is
sensible, but as you say it would be incompatible and so I'll change
it to use XID according to my stated rule above.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services