On 2013-02-03 13:26:25 -0500, Tom Lane wrote:
> 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.
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