Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-02-03 11:17:42 -0500, Tom Lane wrote:
>> -1 on using txids here. If memory serves, we have had exactly this
>> discussion before and rejected spreading those into other parts
>> of the system. That gets rid of three of your problems right there,
>> as well as a lot of ugly hackery with UINT64_FORMAT.
> What about providing something like char *TransactionIdToEpochStrP() and
> implementing it in txid.c instead of transam.c? Not pretty but it
> wouldn't expose much to the outside?
I'm objecting to the entire concept, not just how much cruft gets
exposed outside txid.c.
I went looking for the previous discussion and couldn't find it, but
here are some significant reasons not to use txids for logging:
* They don't have anything to do with the xids you can actually see
in the database (at least not without mod-2^32 arithmetic that is hard
to do in one's head).
* txid_from_xid is very expensive because of the GetNextXidAndEpoch
call; and if it got to be commonly used it would significantly increase
contention for the XidGenLock lock. (Admittedly, two such calls per
VACUUM probably don't mean anything. But once we establish a precedent
of logging txids not xids, there's a slippery slope down to where it
will be a problem.)
* We've found bugs repeatedly in the txid epoch conversion code, and
I have little confidence that there aren't more. (The fact that your
patch found it necessary to touch convert_xid() isn't exactly improving
my opinion of this code, either.) Accordingly, I think that log entries
involving txids would be materially less reliable than if we just print
the xids and have done.
regards, tom lane