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

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On 11 May 2012 17:13, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Hm. This fixes the stability-within-transaction problem, but it's also
>> introduced a change in the definition of age(), no?

> 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.

Well, this definition could also give unexpected readings, depending on
when the first call to age() occurred within the long-running xact.
I'm not sure there's any fix for that unless you want to redefine age()
as a volatile function that uses ReadNewTransactionId on *each* call;
and that doesn't sound like a more useful definition to me.

> What would be more confusing would be to have age() return a different
> result on standby and master.

But surely you can get that anyway, since ReadNewTransactionId is
unlikely to give the same results 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.

I'm not convinced this is the best thing, and I'm definitely not happy
with changing the behavior of working cases (ie, behavior on the master)
in the back branches.

Anybody else have an opinion on this?

regards, tom lane