On 2013-02-03 13:26:25 -0500, Tom Lane wrote: > 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.
Ok, I can live with that. The reason I wanted to log txids instead of plain xids is exactly that youre basically required to do the mod-2^32 arithmetic to understand the numbers, the xids frequently are wrapped around. E.g. the freeze-xid in a somewhat new cluster will be something like 4094966496 which isn't that easy to interpret. Even moreso with relfrozenxids et al. I personally find it relatively hard to compare an xid like 4094966496, even moreso when comparing a wrapped arround value with one not. > The fact that your patch found it necessary to touch convert_xid() > isn't exactly improving my opinion of this code, either. Thats just because it couldn't handle xids that are essentially in epoch -1. E.g. the the freeze limit in a new cluster will wrap-around into that. (~800 - 200mio). Any other opinions on the content of whats being logged? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
