Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
