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

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Ensure age() returns a stable value rather than the latest value
Date: 2012-05-11 16:42:25
Message-ID: CA+U5nMLbJq2CrL-nGa7TWfMsMDag3ARgZ8sF0fThd4_hvfwtfA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On 11 May 2012 17:13, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2012-05-11 17:28:25 Re: Re: [COMMITTERS] pgsql: Ensure age() returns a stable value rather than the latest value
Previous Message Tom Lane 2012-05-11 16:13:23 Re: [COMMITTERS] pgsql: Ensure age() returns a stable value rather than the latest value

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2012-05-11 16:51:01 Re: PL/perl elog(ERROR) Does not Abort Transaction
Previous Message Tom Lane 2012-05-11 16:39:03 Re: PL/perl elog(ERROR) Does not Abort Transaction