Re: Regression tests fail once XID counter exceeds 2 billion

On Sun, Nov 13, 2011 at 6:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> While investigating bug #6291 I was somewhat surprised to discover
> $SUBJECT.  The cause turns out to be this kluge in alter_table.sql:
>
>        select virtualtransaction
>        from pg_locks
>        where transactionid = txid_current()::integer
>
> which of course starts to fail with "integer out of range" as soon as
> txid_current() gets past 2^31.  Right now, since there is no cast
> between xid and any integer type, and no comparison operator except the
> dubious xideqint4 one, the only way we could fix this is something
> like
>
>        where transactionid::text = (txid_current() % (2^32))::text
>
> which is surely pretty ugly.  Is it worth doing something less ugly?
> I'm not sure if there are any other use-cases for this type of
> comparison, but if there are, seems like it would be sensible to invent
> a function along the lines of
>
>        txid_from_xid(xid) returns bigint
>
> that plasters on the appropriate epoch value for an
> assumed-to-be-current-or-recent xid, and returns something that squares
> with the txid_snapshot functions.  Then the test could be coded without
> kluges as
>
>        where txid_from_xid(transactionid) = txid_current()
>
> Thoughts?

Well, the mod-2^32 arithmetic doesn't bother me, but if you're feeling
motivated to invent txid_from_xid() I think that would be fine, too.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company