This is how I solved the xid-wraparound problem for a project I work
on.        The thought of indexing 4-byte xid's gave me nightmares.
[1]

It is based on xxid module from Slony but made keep track of wraparound.
Also I dropped the separate type for xid and made it use regular int8.
Thus no need for lots of type support functions.
The correctness check can be achieved with

        create domain txid as int8 check (value > 0)

It uses relaxed method for wraparound check.  There is a table
txid_wrap (epoch, last_value) which is used to check if the xid
is in current, next or previous epoch.  It requires only occasional
read-write access - ca. after 100k - 500k transactions.

Ofourse it will fail if there will be mo than 2G transactions
between calls to module functions.  So the proper place for
such funtionality would be the code backend, which could also
manage the storage more elegantly.

Now the question is - does the approach have any deficiencies?        
         Would it be useful for Slony?  Would it be useful to push it
upstream in some form?

--
marko

[1] OTOH, I agree with -hackers that there is no point in 8-byte
internal xid - it would be a waste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: txid.tgz
Type: application/x-gzip
Size: 5276 bytes
Desc: not available
Url : http://gborg.postgresql.org/pipermail/slony1-general/attachments/20060119/7bbc259d/txid-0001.bin