"Florian G. Pflug" <fgp@phlo.org> writes:
> Hm.. but xid_age already exposes an implementation detail (that xid
> comparison is circular).
But the only reason anyone cares about it at all, really, is that
xid comparison is circular ... the function was only invented in
the first place to help manage xid-wraparound prevention.
> Actually, after more thought on this I'd
> argue that the only really correct reference for computing a xid's
> age is GetOldestXmin(). It's what VACUUM uses to calculate the
> freezeLimit, after all. Now, using GetOldestXmin() directly is probably
> unwise because it might change at any time. So I now think that
> using RecentOldestXmin is the correct thing to do. The fact that it
> might change between statements for a read-committed transaction
> is quite natural I'd say.
It might change between statements for a serializable transaction too;
or within statements for either kind, because it depends on the actions
of other xacts not just our own. That doesn't seem like a good plan at
all.
If you wanted to cache GetOldestXmin()'s result on first use of xid_age
within a transaction, then okay, but is it worth that much trouble?
Another perspective on this is that ReadNewTransactionId is the correct
reference point for xid_age, because what you really want to know about
when you use it is how much daylight there is before xid wraparound.
So maybe we should redefine xid_age as a volatile function that indeed
uses ReadNewTransactionId on every call. But that is probably going to
complicate use of the function more than is justified.
I note that pg_description defines xid_age as "age of a transaction ID,
in transactions before current transaction", and I'm content to stick
with that definition. Even if it does force consuming an XID. I'm not
sure that we could devise a comparably succinct description of any of
these other proposed behaviors, nor that we should even consider
changing that description.
regards, tom lane