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