Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> Tom Lane wrote:
>>> I don't much like this, since as I mentioned before I don't think
>>> MyProc->xmin is going to be constant over a whole transaction for
>>> long. I don't think xid_age is performance-critical in any way,
>>> so I'd vote for letting it force XID assignment.
>
>> Hm... I agree that xid_age is probably not performance-critical.
>> I guess it's more the complete counter-intuitivity of forcing
>> xid assignment in some arbitrary function thats bugging me a bit.
>
> Well, I don't see it as arbitrary --- we're trying to hide the fact that
> XIDs are assigned lazily from user-visible behavior.
Hm.. but xid_age already exposes an implementation detail (that xid
comparison is circular). 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. After all, read-committed transaction *do*
see changes made by other transaction, so why shouldn't they see
xid age values changing, if this is what those values really do?
Of course, this is very similar to Gregory's suggestion - only that
it uses a cached xid value that already exists, instead of adding
a new one. Plus, it uses a value set once per snapshot instead of
once per transaction.
greetings, Florian Pflug