On 11 May 2012 17:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> Ensure age() returns a stable value rather than the latest value
>
> Hm. This fixes the stability-within-transaction problem, but it's also
> introduced a change in the definition of age(), no? Previously, in an
> xact that had an XID, the age was measured relative to that XID.
> I'm not sure that we should lightly abandon that correspondence.
> At the very least we would need to update the user-facing documentation,
> not only the function's header comment. So far as I can find, the only
> such documentation is the pg_description entry:
> DESCR("age of a transaction ID, in transactions before current transaction");
> but that's still wrong now.
>
> The definition I was thinking of was "if xact has an XID use that, else
> do ReadNewTransactionId, and in either case save the value for later
> calls during the current virtual xact." This is more complicated than
> what you implemented, and maybe we shouldn't be quite that tense about
> backwards-compatibility. But I don't think we should be changing the
> function's definition like you've done in back branches.
Yeh, I thought about that.
The likely difference between the old and the new result is likely to
be small, especially in the main intended use case. The previous
definition was fairly weird, since if you executed it in a long
running transaction it would give a false reading of the actual age,
which ISTM was a bug in itself.
What would be more confusing would be to have age() return a different
result on standby and master.
At present the back branches just throw ERROR, so some change is
needed there at least, given our earlier policy of keeping that ERROR
as a backstop rather than as an acceptable return (re: SQLcode
discussions).
I've no objection to further change, but I think I've done the best
thing out of the various options.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services