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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
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:13:23
Message-ID: 6274.1336752803@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Simon Riggs 2012-05-11 16:42:25 Re: [COMMITTERS] pgsql: Ensure age() returns a stable value rather than the latest value
Previous Message Robert Haas 2012-05-11 13:49:42 pgsql: Prevent loss of init fork when truncating an unlogged table.

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2012-05-11 16:31:10 Re: PL/perl elog(ERROR) Does not Abort Transaction
Previous Message Fujii Masao 2012-05-11 16:13:09 Re: incorrect handling of the timeout in pg_receivexlog