On Sun, Nov 13, 2011 at 6:16 PM, Tom Lane <tgl@sss.pgh.pa.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
