Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers